* Re: [PATCH] Documentation/git-submodule.txt: Further clarify the description
From: Heikki Orsila @ 2008-07-17 13:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080717122911.32334.73465.stgit@localhost>
On Thu, Jul 17, 2008 at 02:29:20PM +0200, Petr Baudis wrote:
> +Submodules allow foreign repositories to be embedded within a dedicated
> +subdirectory of the source tree, always pointed at a particular commit.
> +They are not to be confused with remotes, which are meant mainly for branches
> +of the same project; submodules are meant for different projects you would like
> +to make part of your source tree, while the history of the two projects still
> +stays completely independent and you cannot modify the contents of the
> +submodule from within the main project.
That is nice, thanks!
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply
* [PATCH 2/2 v2] git-gui: "Stage Line": Treat independent changes in adjacent lines better
From: Johannes Sixt @ 2008-07-17 13:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Johannes Sixt
In-Reply-To: <20080716003503.GA24339@spearce.org>
Assume that we want to commit these states:
Old state == HEAD Intermediate state New state
--------------------------------------------------------
context before context before context before
old 1 new 1 new 1
old 2 old 2 new 2
context after context after context after
that is, want to commit two changes in this order:
1. transform "old 1" into "new 1"
2. transform "old 2" into "new 2"
[This discussion and this patch is about this very case and one other case
as outlined below; any other intermediate states that one could imagine are
not affected by this patch.]
Now assume further, that we have not staged and commited anything, but we
have already changed the working file to the new state. Then we will see
this hunk in the "Unstaged Changes":
@@ -1,4 +1,4 @@
context before
-old 1
-old 2
+new 1
+new 2
context after
The obvious way to stage the intermediate state is to apply "Stage This
Line" to "-old 1" and "+new 1". Unfortunately, this resulted in this
intermediate state:
context before
old 2
new 1
context after
which is not what we wanted. In fact, it was impossible to stage the
intermediate state using "Stage Line". The crux was that if a "+" line was
staged, then the "-" lines were converted to context lines and arranged
*before* the "+" line in the forged hunk that we fed to 'git apply'.
With this patch we now treat "+" lines that are staged differently. In
particular, the "-" lines before the "+" block are moved *after* the
staged "+" line. Now it is possible to get the correct intermediate state
by staging "-old 1" and "+new 1". Problem solved.
But there is a catch.
Noticing that we didn't get the right intermediate state by staging
"-old 1" and "+new 1", we could have had the idea to stage the complete
hunk and to *unstage* "-old 2" and "+new 2". But... the result is the same.
The reason is that there is the exact symmetric problem with unstaging the
last "-" and "+" line that are in adjacent blocks of "-" and "+" lines.
This patch does *not* change the way in which "-" lines are *unstaged*.
Why? Because if we did (i.e. move "+" lines before the "-" line after
converting them to context lines), then it would be impossible to stage
this intermediate state:
context before
old 1
new 2
context after
that is, it would be impossible to stage the two independet changes in the
opposite order.
Let's look at this case a bit further: The obvious way to get this
intermediate state would be to apply "Stage This Line" to "-old 2" and
"+new 2". Before this patch, this worked as expected. With this patch, it
does not work as expected, but it can still be achieved by first staging
the entire hunk, then *unstaging* "-old 1" and "+new 1".
In summary, this patch makes a common case possible, at the expense that
a less common case is made more complicated for the user.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
The patch is unmodified, but I hope the commit message is clearer.
-- Hannes
lib/diff.tcl | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index ee7f391..77990c5 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -411,6 +411,53 @@ proc apply_line {x y} {
set hh [lindex [split $hh ,] 0]
set hln [lindex [split $hh -] 1]
+ # There is a special situation to take care of. Consider this hunk:
+ #
+ # @@ -10,4 +10,4 @@
+ # context before
+ # -old 1
+ # -old 2
+ # +new 1
+ # +new 2
+ # context after
+ #
+ # We used to keep the context lines in the order they appear in the
+ # hunk. But then it is not possible to correctly stage only
+ # "-old 1" and "+new 1" - it would result in this staged text:
+ #
+ # context before
+ # old 2
+ # new 1
+ # context after
+ #
+ # (By symmetry it is not possible to *un*stage "old 2" and "new 2".)
+ #
+ # We resolve the problem by introducing an asymmetry, namely, when
+ # a "+" line is *staged*, it is moved in front of the context lines
+ # that are generated from the "-" lines that are immediately before
+ # the "+" block. That is, we construct this patch:
+ #
+ # @@ -10,4 +10,5 @@
+ # context before
+ # +new 1
+ # old 1
+ # old 2
+ # context after
+ #
+ # But we do *not* treat "-" lines that are *un*staged in a special
+ # way.
+ #
+ # With this asymmetry it is possible to stage the change
+ # "old 1" -> "new 1" directly, and to stage the change
+ # "old 2" -> "new 2" by first staging the entire hunk and
+ # then unstaging the change "old 1" -> "new 1".
+
+ # This is non-empty if and only if we are _staging_ changes;
+ # then it accumulates the consecutive "-" lines (after converting
+ # them to context lines) in order to be moved after the "+" change
+ # line.
+ set pre_context {}
+
set n 0
set i_l [$ui_diff index "$i_l + 1 lines"]
set patch {}
@@ -422,19 +469,27 @@ proc apply_line {x y} {
[$ui_diff compare $the_l < $next_l]} {
# the line to stage/unstage
set ln [$ui_diff get $i_l $next_l]
- set patch "$patch$ln"
if {$c1 eq {-}} {
set n [expr $n+1]
+ set patch "$patch$pre_context$ln"
+ } else {
+ set patch "$patch$ln$pre_context"
}
+ set pre_context {}
} elseif {$c1 ne {-} && $c1 ne {+}} {
# context line
set ln [$ui_diff get $i_l $next_l]
- set patch "$patch$ln"
+ set patch "$patch$pre_context$ln"
set n [expr $n+1]
+ set pre_context {}
} elseif {$c1 eq $to_context} {
# turn change line into context line
set ln [$ui_diff get "$i_l + 1 chars" $next_l]
- set patch "$patch $ln"
+ if {$c1 eq {-}} {
+ set pre_context "$pre_context $ln"
+ } else {
+ set patch "$patch $ln"
+ }
set n [expr $n+1]
}
set i_l $next_l
--
1.5.6.1.275.g0a3e0f
^ permalink raw reply related
* Re: Considering teaching plumbing to users harmful
From: Peter Valdemar Mørch @ 2008-07-17 13:35 UTC (permalink / raw)
Cc: git
In-Reply-To: <20080717125536.GO2167@mit.edu>
Theodore Tso tytso-at-mit.edu |Lists| wrote:
> The top-level man page has a listing of what is porcelain and what is
> plumbing --- although there is some disagreement.
Cool! I missed that! Thanks.
> Have you taken a look at the intro-level materials such as "Everyday
> Git in 20 commands or so"[1], the git tutorial[2], the official "Git's
> User Manual"[3], or the "Git-SVN crash course"[4]?
Yup. I started there and am happily coding, committing, branching &
merging away. Now man pages are closest to my fingers in the terminal. :-)
E.g. something I seem to succeed with sometimes, but not consistently is
the equivalent of "svn revert -R .". "git help reset"? Yup: "git reset
--hard HEAD ." When I run into merge conflicts, I'll probably look at
such a doc again, but other than that I'll probably use man pages most.
Just wanted to offer the newbie's opinion, that it would be helpful for
me with "Here be plumbing. Newbies look elsewhere" notices when I'm on
my way down the wrong track.
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* [PATCH] Add a few names to the mailmap
From: Johannes Schindelin @ 2008-07-17 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8ww0j4ye.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1936 bytes --]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I hope that my mailer does not break UTF-8 encoded names...
.mailmap | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/.mailmap b/.mailmap
index f88ae77..ca2e17e 100644
--- a/.mailmap
+++ b/.mailmap
@@ -5,22 +5,28 @@
# same person appearing not to be so.
#
+Alexander N. Gavrilov <angavrilov@gmail.com>
Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
Chris Shoemaker <c.shoemaker@cox.net>
Dana L. How <danahow@gmail.com>
Dana L. How <how@deathvalley.cswitch.com>
Daniel Barkalow <barkalow@iabervon.org>
+David D. Kilzer <ddkilzer@kilzer.net>
David Kågedal <davidk@lysator.liu.se>
+David S. Miller <davem@davemloft.net>
+Dirk Süsserott <newsletter@dirk.my1.cc>
Fredrik Kuivinen <freku045@student.liu.se>
H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
H. Peter Anvin <hpa@trantor.hos.anvin.org>
Horst H. von Brand <vonbrand@inf.utfsm.cl>
+İsmail Dönmez <ismail@pardus.org.tr>
Jay Soffian <jaysoffian+git@gmail.com>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Jon Loeliger <jdl@freescale.com>
Jon Seymour <jon@blackcubes.dyndns.org>
+Jonathan Nieder <jrnieder@uchicago.edu>
Junio C Hamano <junio@twinsun.com>
Karl Hasselström <kha@treskal.com>
Kent Engstrom <kent@lysator.liu.se>
@@ -30,9 +36,11 @@ Li Hong <leehong@pku.edu.cn>
Lukas Sandström <lukass@etek.chalmers.se>
Martin Langhoff <martin@catalyst.net.nz>
Michael Coleman <tutufan@gmail.com>
+Michael W. Olson <mwolson@gnu.org>
Michele Ballabio <barra_cuda@katamail.com>
Nanako Shiraishi <nanako3@bluebottle.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
+Philippe Bruhat (BooK) <book@cpan.org>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Robert Fitzsimons <robfitz@273k.net>
--
1.5.6.3.626.gf5cf.dirty
^ permalink raw reply related
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-17 14:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807171351380.8986@racer>
On Thu, Jul 17, 2008 at 1:58 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 17 Jul 2008, Nigel Magnay wrote:
>
>> On Thu, Jul 17, 2008 at 1:13 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > On Thu, 17 Jul 2008, Nigel Magnay wrote:
>> >
>> >> When doing a git submodule update, it fetches any missing submodule
>> >> commits from the repository specified in .gitmodules.
>> >
>> > Huh? It takes what is in .git/config! Not what is in .gitmodules.
>>
>> Huh? And where does .git/config get it from? Oh, that's right,
>> .gitmodules.
>
> Oh, that's right, after "git submodule init". Right before you are
> supposed to change them if your setup commands that.
>
>> > So if you have another remote (or URL, e.g. if you have ssh:// access,
>> > but the .gitmodules file lists git://), just edit .git/config.
>>
>> So for my usecase, you'd have me go in and change *evey single one* of
>> my submodule refs from the centralised repository, *every time* I want
>> to do a peer review?
>
> No.
>
>> Doesn't the current system strike you as being somewhat centralised in
>> nature?
>
> No.
>
>> > I meant, that is the whole _point_ of having a two-step init/update
>> > procedure.
>>
>> Are you just determined that submodules should remain useless for "the
>> rest of us"?
>
> No.
>
> If you really need to change the "origin" back and forth between reviews,
> while the committed state of the superproject stays the same, then
> something is seriously awkward and needs to be streamlined in your setup.
>
> Because when the superproject's revision stays the same, "git submodule
> update" may fetch additional objects if you specify another remote, but it
> will check out just the same revisions of the submodules. Because they
> were committed as such.
>
> But if you want to get objects from another server (as opposed to update
> the submodules' working directories to the latest committed revisions),
> which happens to have the identical layout of the principal server (which
> I would deem another setup peculiarity to be fixed), you might want to
> look into the recurse patch that was flying about on this list a few
> months back.
The layout wouldn't be the same - the submodules would be in the
corresponding subdirectories (I guess it could have some other,
stranger layout, but I'd consider that peculiar). So you're right, the
layout is different, which makes editing the config all the more
tedious.
I don't want to change the *origin* back and forth. I want to be able
to use repos with submodules in them as easily and as transparently
and in the same distributed way as git allows me to do if they don't
contain submodules. I.E I don't want it to be such a sisyphean
challenge every time with umpteen scripts to complete a usecase that
really ought to be supported as standard. The very first thing that
I've hit is that submodule update only talks to origin, so 'git pull
fred && git submodule update' falls flat on its face. Why am I being
forced to update config just to have a look-see at fred's project?
Your attitude seems to be that the status-quo is in some way
desirable; "It's no wonder that this tool is awkward to use in your
workflow.". This workflow is really common, and there's actual, real
people on this list complaining about it. Don't we think it could be
improved to be non-awkward ?
In the ideal UI, it ought to be possible to make the use of projects
with submodules (almost) completely transparent, like it is in the
vcs-that-dare-not-speak-it's-name.
^ permalink raw reply
* Re: [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Gerrit Pape @ 2008-07-17 14:08 UTC (permalink / raw)
To: git, Eric Wong
In-Reply-To: <20080706192850.32547.qmail@4480698c45f1ed.315fe32.mid.smarden.org>
On Sun, Jul 06, 2008 at 07:28:50PM +0000, Gerrit Pape wrote:
> With subversion 1.5.0 (C and perl libraries) the git-svn selftest
> t9101-git-svn-props.sh fails at test 25 and 26. The following commands
> The breakage was reported by Lucas Nussbaum through
> http://bugs.debian.org/489108
> ---
> git-svn.perl | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> I ran into this on Debian/unstable. With svn 1.5.0 the selftest fails
> without the patch, with svn 1.4.6 it succeeds with and without the
> patch. I'm not familar with the svn interfaces, not sure whether this
> is a regression in subversion, or a bug in git-svn.
Hi, while this commit fixed the selftests, it unfortunately is a
regression
http://thread.gmane.org/gmane.comp.version-control.git/87822/
http://bugs.debian.org/490400
I'm still not sure whether this is a git-svn problem, or actually a
problem in subversion 1.5.0
$ perl -MSVN::Client -e \
'sub print_names { print "<$_[0]>\n"; } $ctx=new SVN::Client;
$ctx->status(".", "BASE", \&print_names, 1, 1, 0, 1);' | head -5
perl:
/build/buildd/subversion-1.5.0dfsg1/subversion/libsvn_subr/path.c:119: svn_path_join: Assertion `is_canonical(base, blen)' failed.
$
[0]
Regards, Gerrit.
[0] http://bugs.debian.org/359679
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Johannes Schindelin @ 2008-07-17 14:16 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170703l57fe26d2h1e9c4db1c38dd6f1@mail.gmail.com>
Hi,
On Thu, 17 Jul 2008, Nigel Magnay wrote:
> Your attitude seems to be that the status-quo is in some way desirable;
> "It's no wonder that this tool is awkward to use in your workflow.".
> This workflow is really common, and there's actual, real people on this
> list complaining about it. Don't we think it could be improved to be
> non-awkward ?
I do not think that the status quo is the best possible.
But I think that the way you go makes things so confusing that those who
use it apart from you will have problems.
For example, in your setup everybody would have to install _different_
remotes in every submodule.
And then some would ask themselves why the original origin was not good
enough.
And others would specify "-o origin" all the time, thinking it was
required.
There must be a better way to promote submodules to a usable state,
Dscho
^ permalink raw reply
* RE: Considering teaching plumbing to users harmful
From: Craig L. Ching @ 2008-07-17 14:21 UTC (permalink / raw)
To: Johannes Schindelin, Avery Pennarun; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807170024310.4318@eeepc-johanness>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Johannes Schindelin
> Sent: Wednesday, July 16, 2008 5:28 PM
> To: Avery Pennarun
> Cc: Junio C Hamano; git@vger.kernel.org
> Subject: Re: Considering teaching plumbing to users harmful
>
> So can those people who have something to say about _my_
> subject of discussion please speak up? I think this issue
> has not been discussed properly.
>
I've read this whole thread with great interest as I started learning
and using git a few months ago. While I agree with you to a degree,
there is a class of "newbies" to git who need more than just the basics
that you outlined. For instance, I'm in the process of evaluating
VCS's, and DVCS's in particular, to replace CVS at our workplace.
Because of that, I need to get "up to speed" as fast as I can. I need
to know about branches, how to browse history, merging, conflicts, etc.
It is true, though, that I have a lot of experience doing these things
already by virtue of the fact that I've used VCS's for over a decade and
have been evaluating DVCS's for at least the past 3 years, so I have a
bit of a head start on these things. To learn about these things,
though, the sheer size of Git's vocabulary is huge compared to other
DVCS's. That's a *good* thing, but it also makes it a bit harder to
learn it all. It's just a fact of life.
The first DVCS I learned was monotone. And I think what helped me the
most in learning it is that it's syntax is very simple (you'd probably
say limited compared to git, but that's neither here nor there, if you
stick to your original list, git is as simple as monotone), it's
repository format, the fact that each developer could keep one
repository and create workspaces off of it was perfect for our
workflows. What I think really helped with learning monotone is that
they had a bunch of common workflows already documented and we could
simply try them out. Maybe if Git had a few different workflows
documented that might help. I know we have a "Git for SVN Users"
workflow, but if you want to move beyond that, it might be good to have
some of the more complex workflows documented. I think some people have
hinted at that suggestion but that maybe it just hasn't been explicitly
said.
> Thanks.
> Dscho
> --
Cheers,
Craig
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Theodore Tso @ 2008-07-17 14:26 UTC (permalink / raw)
To: Peter Valdemar Mørch; +Cc: git
In-Reply-To: <487F4A9A.1090108@morch.com>
On Thu, Jul 17, 2008 at 03:35:22PM +0200, Peter Valdemar Mørch wrote:
> E.g. something I seem to succeed with sometimes, but not consistently is
> the equivalent of "svn revert -R .". "git help reset"? Yup: "git reset
> --hard HEAD ." When I run into merge conflicts, I'll probably look at
> such a doc again, but other than that I'll probably use man pages most.
You find quick alias to be a useful replacement for "svn revert -R
<file>" (aka "hg revert <file>" and "bg revert <file>"):
git config --global alias.revert-file "checkout HEAD --"
Once you run this command, you can now do "git revert-file <file>"
which I personally find very handy. Sometimes I only want to revert
one file, and not all of the files in the working directory, which is
what "git reset --hard" will do.
(Note that "git revert" does something else useful, but which is not
the same as "hg revert", "bk revert" and "svn revert". Oh well, nobody
ever said DSCM's had to be consistent.)
- Ted
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Petr Baudis @ 2008-07-17 14:38 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170508j3d3c1ef8j49df576fc47debe2@mail.gmail.com>
On Thu, Jul 17, 2008 at 01:08:19PM +0100, Nigel Magnay wrote:
> When doing a git submodule update, it fetches any missing submodule
> commits from the repository specified in .gitmodules. If you instead
> want to pull from another repository, you currently need to do a fetch
> in each submodule by hand.
>
> Signed-off-by: Nigel Magnay <nigel.magnay@gmail.com>
I don't think it is good idea to hijack git submodule update for this.
This command has a specific purpose:
"When I pulled new version of the main tree, bring my
submodule checkouts in line with whatever is specified
within the new tree revision."
Your usage scenario has nothing to do with that, it is about "batch
manipulation" of all the submodules at once in a certain way. I think
using the same command for two conceptually pretty much unrelated
purposes will only clutter up the UI, and we should think of a better
general interface pattern for these operations.
In the new git-submodule description, it is said that
"This command will manage the tree entries and contents of the
gitmodules file for you."
and I think we should keep it at this; anything that is related to
submodules, but does not do this directly, would IMHO live better
as some kind of "submodule-recursive" extension of other existing
commands. Say, would this particular need of yours be served by a
hypothetical command like
git checkout --submodules nifty
to check out branch nifty of all submodules or am I misunderstanding
what are you trying to achieve?
If not, then actually even _much_ more elegant solution for this
particular problem would be to store submodule.*.branch in .gitmodules
appropriate to the -b parameter of git submodule add. Then, in branch
'nifty' of the main project, you would set submodule.*.branch to 'nifty'
too. Then, in order to bring all the submodules to the latest version,
I could imagine something like
git pull --submodules
(and possibly just abort at the first sight of a conflict, for
starters).
Let's figure up some UI that is nifty and clean. ;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Contributors, please check your names
From: Jakub Narebski @ 2008-07-17 14:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8ww0j4ye.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> There is a "mailmap" mechanism to consolidate them; it allows us to
> specify what human-readable name should be used for given e-mail address.
> The hypothetical Mr. Thor might want to say "I am A. U. Thor; some commits
> from me, <author@example.xz>, are marked without abbreviating periods in
> my name", and we can add this entry to the toplevel .mailmap file to fix
> it:
>
> A. U. Thor <author@example.xz>
>
> It tells the shortlog (and --pretty=format:%aN in recent enough git)
> mechanism to give huma readable name "A. U. Thor" anytime it sees
> <author@example.xz> e-mail address, regardless of what the Author:
> header in the commit object says.
What about if some authors use different _email_ address, instead?
Is there any way for shortlog to consider them the same?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Petr Baudis @ 2008-07-17 14:51 UTC (permalink / raw)
To: Craig L. Ching; +Cc: Johannes Schindelin, Avery Pennarun, Junio C Hamano, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430238A144@emailmn.mqsoftware.com>
On Thu, Jul 17, 2008 at 09:21:58AM -0500, Craig L. Ching wrote:
> Maybe if Git had a few different workflows
> documented that might help. I know we have a "Git for SVN Users"
> workflow, but if you want to move beyond that, it might be good to have
> some of the more complex workflows documented. I think some people have
> hinted at that suggestion but that maybe it just hasn't been explicitly
> said.
Yes, very recently, someone on #git asked about existing documented
workflows, and there is very little. It would be interesting project for
someone to build a 'Garden of Git Workflows' (or a Labyrinth) - for each
workflow, detailed self-contained documentation ranging from lone developer
with topic branches over repo.or.cz/github forks workflow, the workflows
of "leaf contributors", lieutenants and main integrators of the mail-oriented
kernel/git workflow, up to the single-central-repository workflows.
There are bits here and there, but the main problem is that they are not
self-contained. It might be nice to have something like a set of military
manuals, appropriate for the roles of the particular developers.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] guilt(1): fix path to git-sh-setup
From: Josef 'Jeff' Sipek @ 2008-07-17 14:53 UTC (permalink / raw)
To: Alex Chiang, git
In-Reply-To: <20080716232339.GC22919@ldl.fc.hp.com>
On Wed, Jul 16, 2008 at 05:23:39PM -0600, Alex Chiang wrote:
> git is in the process of moving subcommands to /usr/libexec/git-core
>
> This move breaks an assumption in guilt about the location of
> git-sh-setup.
I already have a fix for this queued up.
Thanks anyway,
Josef 'Jeff' Sipek.
P.S. Pasky: good catch, I'll check the queued up patch to make sure it's not
"broken"
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like
that.
- Linus Torvalds
^ permalink raw reply
* Re: Contributors, please check your names
From: Nicolas Pitre @ 2008-07-17 14:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3sku8sh01.fsf@localhost.localdomain>
On Thu, 17 Jul 2008, Jakub Narebski wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > There is a "mailmap" mechanism to consolidate them; it allows us to
> > specify what human-readable name should be used for given e-mail address.
> > The hypothetical Mr. Thor might want to say "I am A. U. Thor; some commits
> > from me, <author@example.xz>, are marked without abbreviating periods in
> > my name", and we can add this entry to the toplevel .mailmap file to fix
> > it:
> >
> > A. U. Thor <author@example.xz>
> >
> > It tells the shortlog (and --pretty=format:%aN in recent enough git)
> > mechanism to give huma readable name "A. U. Thor" anytime it sees
> > <author@example.xz> e-mail address, regardless of what the Author:
> > header in the commit object says.
>
> What about if some authors use different _email_ address, instead?
> Is there any way for shortlog to consider them the same?
It already does, unless you use the -e switch.
Nicolas
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Nigel Magnay @ 2008-07-17 15:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807171513560.8986@racer>
On Thu, Jul 17, 2008 at 3:16 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 17 Jul 2008, Nigel Magnay wrote:
>
>> Your attitude seems to be that the status-quo is in some way desirable;
>> "It's no wonder that this tool is awkward to use in your workflow.".
>> This workflow is really common, and there's actual, real people on this
>> list complaining about it. Don't we think it could be improved to be
>> non-awkward ?
>
> I do not think that the status quo is the best possible.
>
> But I think that the way you go makes things so confusing that those who
> use it apart from you will have problems.
>
Ok
> For example, in your setup everybody would have to install _different_
> remotes in every submodule.
>
> And then some would ask themselves why the original origin was not good
> enough.
>
> And others would specify "-o origin" all the time, thinking it was
> required.
>
> There must be a better way to promote submodules to a usable state,
My attempt was to try and do some small simple things, but you could
well be right, that might make some commands bloat out with
unneccessary options just to get something done, and that would be
bad.
Stepping back - lets try to come up with a better way (please comment
and and critique)
What we'd like (to start with) is for
$ git pull fred
perhaps with --submodules (as Petr mentions), perhaps with config
settings and caveats, to produce a result that means you don't need to
be aware that there were submodules, they're automatically fetched and
updated based on commits that may only exist in fred's repository.
So currently, you can do
$ git pull origin && git submodule init && git submodule update
And it works, but
$ git pull fred
$ git submodule update
Can leave you with problems, because if a submodule wasn't pushed to
origin, you won't have it available. This is because the commands are
equivalent to
$ git pull fred
for each submodule()
cd submodule
git fetch origin
git checkout <sha1>
So somehow, you need to replace 'git fetch origin' with the "correct"
repository (on fred's computer). My patch was really just about being
able to pass parameters to 'git fetch'. The problems are that if you
did
$ git submodule update fred
Unless each submodule had a [remote] specified for "fred", you'd be
stuffed. But what you could do is either by passing the right URL, or
looking at the superproject [remote] for "fred" - i.e: If in the
superproject you have
[remote "fred"]
url = ssh://git@fred.local/pub/scm/git/workspace/thing/.git
[submodule "module"]
url = ssh://git@repo/pub/scm/git/module.git
Then the submodule "module" on fred, if it's a working-copy, can be calculated
ssh://git@fred.local/pub/scm/git/workspace/thing/module/.git
If it isn't a WC then you'd have to have a [remote "fred"] in that
submodule, but I'm thinking that'd be a rare case.
I'd assumed (possibly wrongly?) that there was resistance to putting
any of the submodule logic in things other than git-submodules.
As a starter for 10, how about
- a '--submodules' option to git fetch / pull
- using the remote name if known, calculate it if not based on the above
WDYT?
^ permalink raw reply
* Re: git submodules and commit
From: Avery Pennarun @ 2008-07-17 15:12 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git Mailing List
In-Reply-To: <320075ff0807170247g7bb18252ma50b202e1d762296@mail.gmail.com>
On 7/17/08, Nigel Magnay <nigel.magnay@gmail.com> wrote:
> Yeah - this happens a lot. If someone else commits to the
> super-project before you, it's always a conflict. What's annoying is
> there's no way around it (though resolution is easy - force to current
> - but it this is a big bit of what confuses my users. They say 'but I
> already resolved the merges in the submodule itself'. I'm not sure
> there's an easy way around it though - and this is part of my worry
> that there's hidden complexity with trying to make it 'look like 1 big
> repo').
This might not be as hard as it sounds. We probably just need to
teach the supermodule how to merge gitlinks safely. So basically, if
I moved the gitlink from A to B, and he moved it from A to C, then it
needs to check whether a fast forward merge already exists for the
submodule to combine B and C. This is easier than it sounds, because
if I *already* ran my newest-git-modules script in the inner module,
then I've already manually resolved the merge in question, so that B
*does* actually contain C.
Right now, such a thing results in a conflict. It isn't really a
conflict though, it's a fast forward, and the supermodule's merge
should ideally just notice that and run with it.
Sadly I know very little about the merge code. But I would be happy
to help you test a patch that implemented this :)
A slightly more advanced version of the same would automatically walk
into the submodule and ask it to merge B and C. I suspect that is way
more complicated than it sounds at first glance, though (particularly
if the new B or C gitlink doesn't have A as a parent at all, which
couldn't happen in a unified git repo, but is perfectly allowable with
submodules).
With anything like this, there's always the question of what happens
if you haven't done a "fetch" in the submodule yet; I think reverting
to the current behaviour is fine in that case, because I can make
newest-git-modules to always fetch before trying anything anyway.
> Yeah. I have an additional usecase, which is around pulling from
> another user. If they've made changes in their tree(s) that they want
> to get reviewed, normally I could do something like
>
> git fetch ssh://joebloggs.computer/blah +refs/heads/*:refs/remotes/joebloggs/*
>
> But if they've made cross-module changes, I'm SOL, as fetching their
> super-project will have references to commits that aren't in the repo
> mentioned in .gitmodules (only in joebloggs's tree) - so doing git
> submodule update doesn't help. I have to go into each submodule and
> explicitly fetch. It feels wierdly centralised for this otherwise
> distributed tool.
One slightly non-obvious option here is to actually use the *same*
repo for all your supermodules and submodules, then use "." as the
repo path in your .gitmodules. The original clone is huge that way,
but it makes it obvious how to get any objects that you're missing.
Then you could construct your submodules using --reference the
supermodule. Thus, doing a "fetch" of your user's supermodule, you'll
also get all the objects it references.
Note that I've only basically tried out this technique. I think it's
the one for me, but I haven't experimented with it enough to know any
pitfalls. When I've brought it up on the list, it's been shot down
because it wouldn't work for gigantic mega-repositories like KDE where
the whole point of submodules is to *not* download all the modules
every time. It works for me, though, because my software doesn't even
*build* unless I have all the modules.
(And before anyone asks, yes, it still makes sense to use submodules
because some of the modules are shared with other projects.)
> What's bugging me is I'm not sure that it's the right place. It seems
> (to me) that having the only place that knows about submodules being
> the 'git submodules' script isn't right. What users want is 'git fetch
> <blah>' to do the lot - that, for the most, it ought to do the
> submodule init, update and clever stuff automatically. That if 'git
> fetch' is porcelain, then the porcelain needs to call the
> git-submodule stuff.
There is some architectural elegance to the fact that the gitlink
stuff is almost completely abstract (just a number, really) in the
core of git, and is only made "real" by running git-submodule, which
actually extracts files and makes .git dirs and fetches submodules and
whatnot.
However, it's architectural elegance, not UI elegance. As a user, I
mostly don't want to have to care whether a particular directory is a
"submodule" or not, so the extra push and commit and fetch steps
become tedious. From the point of view of UI, I agree with you.
Perhaps this is a plumbing vs. porcelain issue. I don't think
git-submodule has made an attempt to separate the two, since it seems
to be porcelain, but there's no "submodule plumbing" underneath
(AFAICS) that things like git-fetch and git-commit and git-push can
plug into.
> But - perhaps it's best to approach it as scripts for now :)
I suspect so :)
> Hm - I'd be happy with the same commt message in all modules. What I
> want is to be able to do (from the top) 'git commit -a' or the same
> with the GUI, and see all the files to be committed regardless of
> whether they're in a submodule or not.
That actually wouldn't work very well for me. I do need the commits
separated, because that's why I'm using submodules in the first place
instead of the "subtree" merge strategy.
Basically, I'm still planning on contributing patches to my class
library upstream, and the patches need to talk about how they affect
the *library*, not what I changed in my application. So I *would*
want to write separate commit messages in all cases. I can see how
other people might not, though.
> This is what the users want - something that mirrors 'svn ci' at the
> top level - "Please Check All My stuff in".
Note that submodules are more like svn:externals, which also require
you to commit each module separately. One big difference there is
that you don't need to commit to the supermodule each time you commit
to the submodule, but that's only because svn:externals by default
links to a branch, not to a particular revision. The
revision-specific linking is very worthwhile, I think, so requiring an
extra commit is mostly okay here.
Perhaps automating the extra commit would be nice in some cases, but
for me, for example, I tend to combine my "update to newest version of
submodule" commit with some changes to the supermodule, since the
reason I updated was to implement this new feature.
Have fun,
Avery
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Jakub Narebski @ 2008-07-17 15:52 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <861w1sn4id.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Daniel Barkalow <barkalow@iabervon.org> writes:
> > You're simply wrong. A ref isn't a name for a commit (the point of
> > having a ref is that it doesn't persist in naming the same commit). A
> > commit isn't a blob. If you start telling people complicated and wrong
> > things, they're surely going to be confused.
A ref is a pointer. In the case of branches it is named pointer
to a commit, "tip of growth" of a branch (to stay with analogy from
biology).
> > Git maintains history as a directed graph, with each commit pointing
> > back at its history. Refs are the what holds the newest commits that
> > nothing else points back to. If directed graphs aren't in your users'
> > experience, you can put it this way: git maintains history like
> > knitting, where each new stitch holds on to one or more previous
> > stitches, and refs are the knitting needles that hold the ends where
> > you're working (except that knitting is a lot wider than software
> > development). gitk --all even provides the diagram you want to explain
> > it.
>
> Complicated and right things are not much less confusing...
For me the idea that commits contain pointers to state of repository
(state of project) at given "time" and pointers to its parents, and
those make history simple yet powerfull one.
Nevertheless simple ideas not always are easily to explain...
> > SVN branches are incredible confusing because they fail to distinguish
> > the directory structure of the project's source tree from the
> > arrangement of available latest versions.
>
> That is because there _is_ no difference. You just store different
> versions in different places. What they are named is a convention,
> nothing more, nothing less.
Branching by copying (!) and tagging by copying (!!!) is abuse
of the fact that copying in Subversion is cheap. Distinguishing
between branch part of directory name by _convention_ is design
mistake; the fact that the tool doesn't help to ensure that
(a) tags lie on branch (b) tags _doesn't change_ is an example
of this stupidity.
> > And the version numbers for your branch increase when changes are made
> > to other branches.
>
> You are confusing "version numbers" which are assigned by humans with
> "revision numbers" which are just an administrational timeline for the
> whole repository.
>
> Really, Subversion is rather simple to understand. But it is not a
> DVCS. Moving a history from one repository to another is not really
> feasible unless you are doing straight mirroring.
Subversion is simple if you are limited to simple things; but the
same is true with Git. I find for example the whole 'properties'
mechanism and its use seriously not simple.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: J. Bruce Fields @ 2008-07-17 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vmykhpn6z.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 16, 2008 at 01:51:31PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Am I the only one who deems teaching plumbing to users ("I like it raw!
> > So I teach it the same way!") harmful?
>
> I think that justification is harmful.
>
> More productive way to think about it is to identify cases where we _need_
> to go down to combination of the plumbing commands in our daily workflow,
> with today's command set. That would give us a good indication that some
> Porcelain may need to be enhanced.
Is there a way to commit the contents of a tarball without using
plumbing? I occasionally want to track an upstream that I know only as
a series of tarballs, so I do something like:
cd repo/
git checkout upstream
rm -rf *
tar -xzvf ../new-version.tar.gz
Then I spend some time mucking around with git-add and git-rm and
eventually end up having to do some sort of git ls-files | git
update-index pipeline.
--b.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: J. Bruce Fields @ 2008-07-17 15:57 UTC (permalink / raw)
To: Petr Baudis
Cc: Craig L. Ching, Johannes Schindelin, Avery Pennarun,
Junio C Hamano, git
In-Reply-To: <20080717145120.GW32184@machine.or.cz>
On Thu, Jul 17, 2008 at 04:51:20PM +0200, Petr Baudis wrote:
> On Thu, Jul 17, 2008 at 09:21:58AM -0500, Craig L. Ching wrote:
> > Maybe if Git had a few different workflows
> > documented that might help. I know we have a "Git for SVN Users"
> > workflow, but if you want to move beyond that, it might be good to have
> > some of the more complex workflows documented. I think some people have
> > hinted at that suggestion but that maybe it just hasn't been explicitly
> > said.
>
> Yes, very recently, someone on #git asked about existing documented
> workflows, and there is very little. It would be interesting project for
> someone to build a 'Garden of Git Workflows' (or a Labyrinth) -
That's been requested for a long time, but nobody's gotten around to it.
It might be nice if it could be made a superset of everyday.txt.
--b.
> for each
> workflow, detailed self-contained documentation ranging from lone developer
> with topic branches over repo.or.cz/github forks workflow, the workflows
> of "leaf contributors", lieutenants and main integrators of the mail-oriented
> kernel/git workflow, up to the single-central-repository workflows.
>
> There are bits here and there, but the main problem is that they are not
> self-contained. It might be nice to have something like a set of military
> manuals, appropriate for the roles of the particular developers.
>
> --
> Petr "Pasky" Baudis
> GNU, n. An animal of South Africa, which in its domesticated state
> resembles a horse, a buffalo and a stag. In its wild condition it is
> something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Karl Hasselström @ 2008-07-17 16:03 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20080717155538.GE11759@fieldses.org>
On 2008-07-17 11:55:38 -0400, J. Bruce Fields wrote:
> Is there a way to commit the contents of a tarball without using
> plumbing?
contrib/fast-import/import-tars.perl
It currently lacks a bit in flexibility, IIRC, but it does its job
well.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: David Kastrup @ 2008-07-17 16:05 UTC (permalink / raw)
To: git
In-Reply-To: <m3od4wse30.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> > SVN branches are incredible confusing because they fail to
>> > distinguish the directory structure of the project's source tree
>> > from the arrangement of available latest versions.
>>
>> That is because there _is_ no difference. You just store different
>> versions in different places. What they are named is a convention,
>> nothing more, nothing less.
>
> Branching by copying (!) and tagging by copying (!!!) is abuse
> of the fact that copying in Subversion is cheap.
Uh, no. A lot of work has been invested into ensuring that copying in
Subversion in cheap _exactly_ because of the design decision to
implement branching and tagging via copying.
It is not an accident that copying is cheap.
> Distinguishing between branch part of directory name by _convention_
> is design mistake; the fact that the tool doesn't help to ensure that
> (a) tags lie on branch (b) tags _doesn't change_ is an example of this
> stupidity.
How much have you worked with Subversion so far? I am doing quite a bit
of work with it, and the do-everything-via-copying paradigm does not get
in my hair. It actually means that I have to remember fewer commands.
And it is pretty easy to understand.
>> Really, Subversion is rather simple to understand. But it is not a
>> DVCS. Moving a history from one repository to another is not really
>> feasible unless you are doing straight mirroring.
>
> Subversion is simple if you are limited to simple things; but the
> same is true with Git. I find for example the whole 'properties'
> mechanism and its use seriously not simple.
Granted, particularly concerning the external property. OTOH, it makes
the equivalent of git submodules rather cheap (and I actually still have
no idea how git submodules properly work and what implications they
have).
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 0/4] Honor core.deltaBaseCacheLimit during index-pack
From: Stephan Hennig @ 2008-07-17 16:06 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Nicolas Pitre, Andreas Ericsson,
Johannes Schindelin, Jakub Narebski, Junio C Hamano
In-Reply-To: <20080715024741.GB1700@spearce.org>
Shawn O. Pearce schrieb:
> We're better off keeping our memory usage low and recomputing
> the delta base when we need to return to it to process a sibling.
Thanks to all who have had a look at this issue! From a user's
perspective I have one more suggestions and a question:
First, it would have helped me to bring this issue onto the list if I
had earlier known that this was no misconfiguration, but a memory
problem. Even though Git now makes some efforts to substitute runtime
for memory to be able to operate with low(er) memory, I think it would
still be informative for a user that repository and hardware, resp.
core.deltaBaseCacheLimit, are, say, incompatible. If valuable objects
have to be discarded due to memory restrictions a warning could be
issued to make the user aware of this fact, e.g.,
Warning! Low memory. Git might be slowing down.
Second, while there have been some changes to Git now, as a poor user,
how can I make use of that changes? I think, updating my client should
only help with pushing. For pulling, I have to wait for repo.or.cz to
update to Git 1.6.0, right?
Best regards,
Stephan Hennig
^ permalink raw reply
* Subversion is actually not so simple (was RE: Considering teaching plumbing to users harmful)
From: Craig L. Ching @ 2008-07-17 16:11 UTC (permalink / raw)
To: Jakub Narebski, David Kastrup; +Cc: git
In-Reply-To: <m3od4wse30.fsf@localhost.localdomain>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Jakub Narebski
> Sent: Thursday, July 17, 2008 10:52 AM
> To: David Kastrup
> Cc: git@vger.kernel.org
> Subject: Re: Considering teaching plumbing to users harmful
>
> Subversion is simple if you are limited to simple things; but
> the same is true with Git. I find for example the whole 'properties'
> mechanism and its use seriously not simple.
>
Yes, that's exactly right. Because SVN's underlying repository is
complex, it sometimes falls out in the UI. If you stick with the way
SVN wants you to do things, you can get along with it fairly well. But
that's the problem, it's just not flexible. On the other hand, Git's
concept of the repository is so simple and clean, it's a DAG and you can
actually do a lot more with fewer commands. But then you can do so much
more as well and work the way *you* want to.
For instance, SVN has a history of having to invent concepts that just
shouldn't need to be invented. Their latest release includes something
they call "merge tracking", but it falls on the floor in the face of
what they call "reflective merging." [1] I don't find "merge tracking"
and "reflective merges" concepts that I should *have* to understand when
it comes to working with a VCS, the VCS should just *do* those things.
Those concepts just don't exist in Git. Frankly, I don't find
Subversion to be easier to use than Git at all and this is coming from a
very long-time CVS user. I do find, however, that Git has a very large
vocabulary and that does take some time to learn, but I'd argue that
this is due to it's inherent flexibility than it is due to any inherent
flaws.
[1] -- http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
> --
Cheers,
Craig
^ permalink raw reply
* Subversion's do-everything-via-copying paradigm ( was RE: Re: Considering teaching plumbing to users harmful)
From: Craig L. Ching @ 2008-07-17 16:18 UTC (permalink / raw)
To: David Kastrup, git
In-Reply-To: <86k5fk1ooq.fsf@lola.quinscape.zz>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of David Kastrup
> Sent: Thursday, July 17, 2008 11:05 AM
> To: git@vger.kernel.org
> Subject: Re: Considering teaching plumbing to users harmful
>
> How much have you worked with Subversion so far? I am doing
> quite a bit of work with it, and the
> do-everything-via-copying paradigm does not get in my hair.
> It actually means that I have to remember fewer commands.
> And it is pretty easy to understand.
>
Does it not bother you that renaming a file is a copy + delete [1].
Have they fixed that yet? That was one of the biggest reasons we never
moved to subversion.
Ok, I'm done picking on Subversion for now :-P
[1] -- http://subversion.tigris.org/issues/show_bug.cgi?id=898
> --
> David Kastrup
>
Cheers,
Craig
^ permalink raw reply
* Re: Contributors, please check your names
From: Junio C Hamano @ 2008-07-17 16:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3sku8sh01.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> What about if some authors use different _email_ address, instead?
> Is there any way for shortlog to consider them the same?
Read the first part of the message you are responding to again please.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox