Re: RFC: repository of handy git aliases?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jon Seymour venit, vidit, dixit 18.08.2011 16:52:
> On Tue, Aug 16, 2011 at 11:55 PM, Michael J Gruber
> <git@xxxxxxxxxxxxxxxxxxxx> wrote:
>> Jon Seymour venit, vidit, dixit 08.08.2011 12:43:
>>> On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote:
>>>> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@xxxxxxxxx> wrote:
>>>>> On 8/8/11, Jon Seymour <jon.seymour@xxxxxxxxx> wrote:
>>>
>>> I've also added this...
>>>
>>> Listing the tips of branches in pu that are not in master
>>> ===========================================
>>>
>>> Suppose you have two aliases defined like so:
>>>
>>> [alias]
>>>         oneline = !/usr/bin/xargs -L1 git log --decorate --max-count=1 --oneline
>>
>> How about
>>
>> oneline = git log --no-walk --decorate --oneline
> 
> I still need to !/usr/bin/xargs -L1m, don't I? The point is to
> transform a list of SHA1s into a decorated list. But point taken about
> --no-walk being an alternative to --max-count=1.

Is this a typo or do you have an xargs which understands "1m"? My point
was that you can feed all tips to "log" at once, as long as you don't
exceed the argument list limits, of course.

>> git branch --merged origin/pu --contains origin/next
>>
>> (or with --no-merged, but put it first.)
>>
> 
> So, the idea with tips is that it will show you the tips of
> independent lines of development that have diverged from origin/next
> (or before) that have been merged back into origin/pu. This works,
> even if you don't have branches assigned to these tips.

OK, that is different then.

[snipped discription]
> 
> 

[readding relevant part:]
>>> b166408 mergetool: Don't assume paths are unmerged
>>> b29d76f merge: mark the final "Merge made by..." message for l10n
>>>942cf39 receive-pack: Allow server to refuse pushes with too many objects

>>>
>>> which is a list of the tips of branches that are in pu, but not in next.
>>
>> That's not quite the standard --decorate, is it? ;)
>>
> 
> Not sure what you mean by not being standard? The main idea about
> using --decorate here is to get a dump of any refs that might describe
> the identified tips.

Just compare your output with this:

git log --decorate --no-walk --oneline origin/{master,next,pu}
a46e511 (origin/pu) Merge branch 'fg/submodule-git-file-git-dir' into pu

0e3f8f0 (origin/next) Merge branch 'master' into next

4bfe7cb (origin/master, origin/HEAD) Sync with "maint"

That is, I get the branch decorations there; you use the same format but
don't get any. But I may be misunderstanding completely what you are
trying to achieve. I guess I have to reread your extended use case
description...

Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]