RFC: repository of handy git aliases?

RFC: repository of handy git aliases?

[Jon Seymour]

I was wondering if there is any interest in establishing a wiki page
or gist repository of git aliases that people find useful?

jon.

Re: RFC: repository of handy git aliases?

[Jakub Narębski]

On 8/8/11, Jon Seymour <jon.seymour@gmail.com> wrote:
> I was wondering if there is any interest in establishing a wiki page
> or gist repository of git aliases that people find useful?

https://git.wiki.kernel.org/index.php/Aliases

-- 
Jakub Narebski

Re: RFC: repository of handy git aliases?

[Jon Seymour]

On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> wrote:
>> I was wondering if there is any interest in establishing a wiki page
>> or gist repository of git aliases that people find useful?
>
> https://git.wiki.kernel.org/index.php/Aliases
>

Ah, thanks. I added this link

        Aliases - for list of handy tools implemented as git aliases.

to:

       https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#See_also

since that is where I expected to find a link when I looked. (Of
course, I should have searched, but I didn't!)

jon.

Re: RFC: repository of handy git aliases?

[Jon Seymour]

On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> 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
        tips = "!_() { t=$(git rev-list --no-merges --max-count=1
\"$@\"); if test -n \"$t\"; then echo $t; _ \"$@\" ^$t; fi; }; _"

Then:

git tips origin/pu ^origin/next | git oneline

might show something like this:

9dcca58 filter-branch.sh: de-dent usage string
704c335 On Cygwin support both UNIX and DOS style path-names
1c460f9 t3030: fix accidental success in symlink rename
9e81372 test-path-utils: Add subcommand "prefix_path"
ad733bd revert: Propagate errors upwards from do_pick_commit
76cf946 fixup! xdiff/xhistogram: rework handling of recursed results
df6a9c7 fixup! describe: Refresh the index when run with --dirty
c9f57a0 squash! ls-files: fix pathspec display on error
a1288bc add--interactive: add option to autosplit hunks
365b78a t5800: point out that deleting branches does not work
c997182 limit "contains" traversals based on commit generation
914b6fb doc/fast-import: document feature import-marks-if-exists
b792c06 branch -v: honor core.abbrev
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.

Re: RFC: repository of handy git aliases?

[Jon Seymour]

On Mon, Aug 8, 2011 at 8:43 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> wrote:
>
> I've also added this...
>
> Listing the tips of branches in pu that are not in master
> ===========================================
>

master -> next

Re: RFC: repository of handy git aliases?

[Michael J Gruber]

Jon Seymour venit, vidit, dixit 08.08.2011 12:43:
> On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> 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

>         tips = "!_() { t=$(git rev-list --no-merges --max-count=1
> \"$@\"); if test -n \"$t\"; then echo $t; _ \"$@\" ^$t; fi; }; _"
> 

That one is way over my head, but if

> Then:
> 
> git tips origin/pu ^origin/next | git oneline

is your typical use case you may like

git branch --merged origin/pu --contains origin/next

(or with --no-merged, but put it first.)

> might show something like this:
> 
> 9dcca58 filter-branch.sh: de-dent usage string
> 704c335 On Cygwin support both UNIX and DOS style path-names
> 1c460f9 t3030: fix accidental success in symlink rename
> 9e81372 test-path-utils: Add subcommand "prefix_path"
> ad733bd revert: Propagate errors upwards from do_pick_commit
> 76cf946 fixup! xdiff/xhistogram: rework handling of recursed results
> df6a9c7 fixup! describe: Refresh the index when run with --dirty
> c9f57a0 squash! ls-files: fix pathspec display on error
> a1288bc add--interactive: add option to autosplit hunks
> 365b78a t5800: point out that deleting branches does not work
> c997182 limit "contains" traversals based on commit generation
> 914b6fb doc/fast-import: document feature import-marks-if-exists
> b792c06 branch -v: honor core.abbrev
> 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? ;)

Michael

Re: RFC: repository of handy git aliases?

[Jon Seymour]

On Tue, Aug 16, 2011 at 11:55 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Jon Seymour venit, vidit, dixit 08.08.2011 12:43:
>> On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>>> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>>> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> 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.

> 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.

In this example:

A-----B---E---F---G---H
\-----C--/   /
 \ ----D----/

git tips F will show B, C, D as the tips of branches that have
diverged from the mainline but have merged back in.

If I want to rebuild F' which does not include C, then git tips F
tells me that I have to merge B and D.

The git tips alias abstracts the function of 'git work list
dependency' which is a function of git extension (git work) that I
have been playing around with for a while.

I use git work to manage a private integration branch which includes
all my current published but unintegrated-upstream topics. If I decide
I want to unmerge one of these topics from my integration branch, I'd
do something like:

     git work unmerge C

Which does the equivalent of:

   git checkout B
   git merge D
   git rebase --onto HEAD F H


>>
>> 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.

jon.

Re: RFC: repository of handy git aliases?

[Michael J Gruber]

Jon Seymour venit, vidit, dixit 18.08.2011 16:52:
> On Tue, Aug 16, 2011 at 11:55 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Jon Seymour venit, vidit, dixit 08.08.2011 12:43:
>>> On Mon, Aug 8, 2011 at 8:22 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>>>> On Mon, Aug 8, 2011 at 7:45 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>>>> On 8/8/11, Jon Seymour <jon.seymour@gmail.com> 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

Re: RFC: repository of handy git aliases?

[Jon Seymour]

On Fri, Aug 19, 2011 at 1:40 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> 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.

Yeah, meant -L1, not -L1m.

Ok, so you are suggesting something like: git oneline $(git tips
origin/pu ^ origin/next) instead of

    git tips origin/pu ^origin/next | git oneline

I guess it comes down to a preference thing, but it is good to know
that with --no-walk I can do it either way, so thanks!

Here's a alias definition for oneline that does it both ways,
depending on preference...

[alias]
        oneline ="!_() { if test $# -eq 0; then xargs -L1 git log
--no-walk --decorate --oneline; else git log --no-walk --decorate
--oneline \"$@\"; fi; }; _"

>>
>> 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...
>

Ok, so the only reason my output didn't show any tags is that there
didn't happen to be any.

With a local integration branch, there usually will be local
references that explain each tip. So, for example, git tips master for
me currently shows:

git tips master | git oneline  shows:

f85a051 (kernel/master) Update draft release notes to 1.7.7
9e90d12 (refactor) rename auto-edit -> refactor.
e586f2e (gitwork-dist) Regenerate git-work.zip
dbb64d9 (tag: gitwork-v0.0.11, public/gitwork, gitwork) git-work:
update documentation.
272277f (bisect-gettextln) bisect: take advantage of gettextln, eval_gettextln.

So this does show helpful decorations. The reason git tips origin/pu
^origin/next | git oneline doesn't show any decorations is simply
because I don't have any tags or branches that represent those tips -
Junio presumably does, for example.

Note also that git tips doesn't show merge commits.

The best way to understand what git tips does is to do this:

     gitk origin/pu ^origin/next --no-merges

The commits reported by git tips are the tips of each linear stream of
development you see in gitk.

jon.