* Re: Some git performance measurements..
From: Nicolas Pitre @ 2007-11-29 3:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711281852160.8458@woody.linux-foundation.org>
On Wed, 28 Nov 2007, Linus Torvalds wrote:
> - the index accesses are much more "random": the initial 256-way fan-out
> followed by the binary search causes the access patterns to look very
> different:
>
> 0: 28367707
> 136: 18867574
> 140: 221280
> 141: 745890
> 142: 284427
> 143: 338
> 381: 9787459
> 377: 394
> 375: 255
> 376: 248
> 3344: 29885989
> 3347: 334
> 3346: 255
> 3684: 7251911
> 1055: 12954064
> 1052: 386
> 1050: 251
> 1049: 240
> 1947: 10501455
> 1944: 382
> 1946: 262
>
> where it doesn't even read-ahead at all in the beginning (because it
> looks entirely random), but the kernel eventually *does* actually go
> into read-ahead mode pretty soon simply because once it gets into the
> binary search thing, the data entries are close enough to be in
> adjacent pages, and it all looks ok.
Did you try with version 2 of the pack index? Because it should have
somewhat better locality as the object SHA1 and their offset are split
into separate tables.
> That said, I think there's something subtly wrong in our pack-file
> sorting, and it should be more contiguous when we just do tree object
> accesses on the top commit. I was really hoping that all the top-level
> trees should be written entirely together, but I wonder if the "write out
> deltas first" thing causes us to have those big gaps in between.
Tree objects aren't all together. Related blob objects are interlaced
with those tree objects. But for a checkout that should actually
correspond to a nice linear access.
And deltas aren't written first, but rather their base object. And
because deltas are based on newer objects, in theory the top commit
shouldn't have any delta at all, and the second commit should have all
the base objects for its deltas already written out a part of the first
commit. At least that's what a perfect data set would produce. Last
time I checked, there was about 20% of the deltas that happened to be in
the other direction, i.e. the deltified object was younger than its base
object, most probably because the new version of the file shrunk instead
of growing which is against the assumption in the delta search
object sort. But again, because the base object is needed to resolve
the delta, it will be read anyway.
Nicolas
^ permalink raw reply
* Re: can't commit files that have been git add'ed because "fatal: you need to resolve your current index first"
From: Bill Priest @ 2007-11-29 4:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, 28 Nov 2007 12:08:40 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> Bill Priest <priestwilliaml@yahoo.com> writes:
>
> > I merged from one branch to another and had lots
of
> > conflicts. I've resolved a set of files from the
> > conflicts (in a directory) and did a git-add on
this
> > set of files. I wasn't able to commit these
files.
> > On IRC I was told that all files must be resolved
> > before I can commit any of them. This seems
pretty
> > limiting.
>
> You have two parallel development lines that lead to
A and B and trying
> to come up with a "merge" M:
>
> o---o---A
> / \
> ---o---o---B---M
>
> What property should the merge commit "M" have? It
must keep the
> changes made on the upper line to make it better
than B, and it must
> keep the changes made on the lower line to make it
better than A.
Ok. One thing I probably wasn't clear on is these are
two distinct
product lines that share a great amount of code;
however, much of the
code is "incompatible". The two branches will never
be "merged" into
one "mainline" as the underlying hardware is by
definition
incompatible. In theory I could use a bunch of
conditional compilation
to unify the two lines; however, this means that every
time I make a
change to one branch I have to make sure that it
doesn't break the
other one. It would have been better if the code was
modularized
better to just include different files for the two
versions;
unfortunately this is easier said than done. I guess
you could think
of it line a 2.4 kernel vs. a 2.6 kernel; but in the
same repository.
So to sum it up there are changes in branch A that
will never go into
branch B (and vice versa); however, there are a number
of changes that
need to go into both. Unfortunately the rest of my
team uses
subversion and isn't even aware that I am using git
(we recently switch
to subversion from cvs, so it is a hard sell to
management to switch
again). I'm responsible for keeping bug fixes and new
features in both
product lines and I found subversion's merging to be
utterly useless.
> Let's say both upper and lower lines of development
touched files frotz
> and xyzzy in overlapping, different ways. You try
to merge A while you
> are at B and see conflicts in these two files.
>
> Let's say you resolved frotz; the contents in frotz
is in a desired
> shape, i.e you have the changes you want from the
line led to A and the
> other line led to B. But you haven't resolved xyzzy
yet.
>
> You seem to want to make this half-resolved state as
a commit. First
> question: what contents would you want to commit for
xyzzy?
As an example there is a directory in the tree that is
a program that
runs on a PC (vs. the other stuff that runs on
embedded processors) it
shares a handful of include files w/ the embedded side
for packet
definition but it is otherwise completely separate
from the programs
that run on the embedded processors. Once I complete
merging of this
directory and it builds it is ready to go. The
remaining merges have
no effect on this PC based program. I'm not sure if
it is possible or
not but if I could merge this directory and below
(does git support
this??) it might be one way of handling it or if I
cherry-pick'ed it
that could also work. This isn't always feasible as
the other users
often check in wholesale changes into subversion as
one change set
(remember that these are former cvs users that have
lots of bad habits
to lose). It would be great if branches were created
for each
"logical" change and checked in in one changeset; this
seems to be what
git is expecting (in a perfect world this would always
be the case).
>
> If you commit the contents from B (because you
started from it), then it
> should not be recorded as a proper merge. If you
did so, merging that
> back to A would obliterate all the work done up to A
to file xyzzy:
>
> o---o---A...X
> / \ .
> ---o---o---B---*
>
> because merge base of A and * (I am marking it
differently because such
> an incomplete merge should not be made) is A, so the
result (X) will be
> the half-merge * itself (fast forward). That's not
a merge as it is not
> better than A -- you discarded improvements made to
xyzzy by people who
> built up to A.
>
> This is inherent to what a merge is. With proper
understanding of what
> a merge is, you would not feel this limiting at all.
I've used clearcase in the past and although there
were many things I
didn't like about it (big, slow, costs $$$$, network
pig, needs a super
server, etc.) it did allow commits of files at any
time and tracked the
files that were merged independently. I know that git
tracks changes
and not files; but in the end you have to pick file(s)
or pieces of
them to be committed; having the tool restrict me from
committing files
because of the way it tracks merges IS limiting IMHO.
I guess the big
difference is that in kernel land you can reject
patches until they are
broken up into "atomic" pieces (I don't really have
the option of
reversing the subversion commit and turning it into
"atomic" commits).
> Having said that, I think something like the
following _could_ be done,
> although I do not know if it makes much sense.
>
> (1) Try merge, see it conflict, resolve only a part
of it, and record
> the result as "WIP to merge in A". Do not
record it as a merge, as
> it is not. diff between B and M will contain a
squash merge of A on
> top of B minus the changes to the path xyzzy.
>
> o---o---A
> /
> ---o---o---B---M
>
> (2) Fix up the conflicts in xyzzy to resolve the
conflicts fully, and
> record the result as "Final merge of A into B".
This should be
> recorded as a merge, as the result is "keeping
changes done on both
> branches to come up with something better than
either of them."
>
> o---o---A---,
> / \
> ---o---o---B---M---N
>
> If you look at the topology a bit differently, the
above actually makes
> some sense:
>
> .---o---o---A
> / \
> ---o---o---B---M---N
>
> That is, instead of merging A into B, you made
"preparatory changes" to
> branch B in order to make it easier to merge A.
That's what the commit
> M is about.
>
> Then you merge A on top of M. In reality, because
the difference
> between B to M contains most of the squash merge of
A into B, such a
> merge N will contain many accidental clean merges.
But in git,
> accidental clean merges are not a problem (people
can apply the same
> patch to their trees and later their branches can be
merged).
>
> But "git commit" after a conflicted merge will
always create a merge,
> and there is no canned option to do multi-step merge
like the above.
>
> You can still do that by hand, by doing something
like:
>
> $ git merge --squash A
> $ resolve only partly
> $ git commit -m 'Prepare to merge A'
> $ git reset --hard
> $ git merge A
> $ resolve the rest
> $ git commit -m 'Fully merged A'
Ok. I did a git merge --squash. So I should be able
to try this.
After I resolve only partly; I'm assuming that I git
checkout HEAD any
files that I don't want yet and then do the commit?
Assuming that I
commit the partial after throwing away any merges that
I wasn't ready
to do (via git checkout HEAD); what does the "git
reset --hard" do?
> For such a multi-step merge to make sense, the
change between B---M
> should make sense by itself for people who have to
read such a history
> later. Such a half-a-squash-merge may probably not
make sense by itself
> in most cases, so I suspect the above workflow would
not be useful in
> general.
I would agree for the case where in the end you really
only have one
product; but again think like you have a 2.4 kernel
and a 2.6 kernel in
the same repository. For most embedded development
(I've been doing it
for 20+ years) there is always newer hardware that
changes processors,
add features, gets all the new development while the
"old" production
board is still shipping and in customers hands and
needs bug fixes and
the occassional new feature. It doesn't make sense to
have two
separate repositories when much of the code is the
same and is likely
to need the same fixes.
Junio,
Thanks for your time and insight; git has already
saved me
countless hours and has certainly come a long way in a
very short
time. I'll give your multi-step merge a shot and see
how well it works
for my code base. I'm sure there are better ways to
structure my code
base to get what I am looking for; but as is usually
the case the rules
of the game have changed as I have been playing it
(the old hardware
was supposed to die and never be touched again; HA
HA).
Regards,
Bill
____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/
^ permalink raw reply
* Re: Some git performance measurements..
From: Linus Torvalds @ 2007-11-29 4:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0711282244190.9605@xanadu.home>
On Wed, 28 Nov 2007, Nicolas Pitre wrote:
>
> Tree objects aren't all together. Related blob objects are interlaced
> with those tree objects.
Yeah, I noticed that a few minutes after saying this.
> But for a checkout that should actually correspond to a nice linear
> access.
For the initial check-out, yes. But the thing I timed was just a plain
"git checkout", which won't actually do any of the blobs if they already
exist checked-out (which I obviously had), which explains the non-dense
patterns.
The reason I care about "git checkout" (which is totally uninteresting in
itself) is that it is a trivial use-case that fairly closely approximates
two common cases that are *not* uninteresting: switching branches with
most files unaffected and a fast-forward merge (both of which are the
"two-way merge" special case).
I also suspect it is pretty close to a real three-way merge (again, with
just a few files changed).
IOW, there's a lot of these "tree operations" that actually leave 99% of
the tree totally unchanged, at least in the kernel. Even a fairly big
merge tends to change just a few hundred files. And when there are 23,000
files in the tree, a few hundred files is a fairly small percentage!
So it's actually fairly common to have "git checkout"-like behaviour with
no blobs needing to be updated, and the "initial checkout" is in fact
likely a less usual case. I wonder if we should make the pack-file have
all the object types in separate regions (we already do that for commits,
since "git rev-list" kind of operations are dense in the commit).
Making the tree objects dense (the same way the commit objects are) might
also conceivably speed up "git blame" and path history simplification,
since those also tend to be "dense" in the tree history but don't actually
look at the blobs themselves until they change.
Linus
^ permalink raw reply
* Re: Some git performance measurements..
From: Junio C Hamano @ 2007-11-29 5:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711281747450.8458@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Less than a hundredth of a second may not sound much, but when we have
> 1700+ directories in the kernel trees, doing that for each possible
> .gitignore file is really really expensive!
The only thing that wants to use excluded() in the unpack_trees()
codepath is the code to allow overwriting an existing, untracked file in
verify_absent(). When we find an untracked file at the same path as we
are just trying to check out a file, we allow overwriting it only if
that file is "ignored".
But the way the unpack_trees_rec() and the gitignore handling in dir.c
are structured currently means we do push/pop exclude-per-directory
stack as we enter and leave a new subdirectory. We do not do this
lazily on demand.
The newer gitattributes subsystem maintains a similar per-directory data
structure but this is purely done on-demand; until somebody asks "what
are the attrs for this path", we do not read .gitattributes file. We
should be able to restructure exclude-per-directory code in a similar
way.
^ permalink raw reply
* Re: git guidance
From: Al Boldi @ 2007-11-29 5:27 UTC (permalink / raw)
To: linux-kernel; +Cc: git
In-Reply-To: <200711282130.12864.a1426z@gawab.com>
Jakub Narebski wrote:
> Al Boldi wrote:
> > Johannes Schindelin wrote:
> >> By that definition, no SCM, not even CVS, is transparent. Nothing
> >> short of unpacked directories of all versions (wasting a lot of disk
> >> space) would.
> >
> > Who said anything about unpacking?
> >
> > I'm talking about GIT transparently serving a Virtual Version Control
> > dir to be mounted on the client.
>
> Are you talking about something like (in alpha IIRC) gitfs?
>
> http://www.sfgoth.com/~mitch/linux/gitfs/
This looks like a good start.
> Besides, you can always use "git show <revision>:<file>". For example
> gitweb (and I think other web interfaces) can show any version of a file
> or a directory, accessing only repository.
Sure, browsing is the easy part, but Version Control starts when things
become writable.
Thanks for the link!
--
Al
^ permalink raw reply
* Re: [PATCH/RFC] Teach repack to optionally retain otherwise lost objects
From: Junio C Hamano @ 2007-11-29 6:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0711290340470.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Besides, a completely different idea just struck me: before
> repacking, .git/objects/pack/* could be _hard linked_ to the
> forkee's object stores. Then nothing in git-repack's code
> needs to be changed.
>
> Oh, well. I just wasted 1.5 hours.
Your 1.5 hours was spent wisely to come up with that idea ;-).
To make sure I understand your idea correctly, the procedure to repack a
repository in a fork-friendly way is:
(1) find the project directly forked from you;
(2) hardlink all packs under your object store to their object store;
(3) repack -a -l and prune.
I think that would work as long as you do the above as a unit and handle
one repository at a time. Otherwise I think you risk losing necessary
objects when hierarchical forks are involved. E.g. if you have a
project X that has a fork Y which in turn has fork Z.
* Step 1 is run for X, Y and Z.
* Step 2 is run for Y and Z.
* Step 3 is run for Z.
At this point, Z is still borrowing objects from Y and X through Y, and
it will not keep objects it is borrowing from X through Y. Then if the
procedure is intermixed like this, a bad thing happens.
* Step 2 is run for X.
* Step 3 is run for Y.
* Step 3 is run for X.
Step 3 for Y would lose objects Y was borrowing from X that were not
used by Y itself. At this point, Z is still usable as the objects it is
borrowing from X though Y have not been pruned from X. But Step 3 for X
will lose them, rendering Z unusable.
^ permalink raw reply
* Re: [PATCH v3] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-29 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vve7m0wfo.fsf@gitster.siamese.dyndns.org>
On Nov 28, 2007, at 3:42 PM, Junio C Hamano wrote:
> I do not think reporting back the rewritten object name makes much
> sense
> nor adds any value; it won't be useful information until you fetch the
> object.
Right, this was mostly in anticipation of doing an automatic fetch, so
that I would avoid fetching anything but the rewritten revisions; if I
just fetched the remote ref as normal, then I'd potentially pick up
unrelated changes that happened to hit just after my pack was
accepted, which wouldn't maintain the "update the tracking ref to
point to what I just pushed" semantics.
Since it sounds like that's a nonstarter, I agree this part of the
patch isn't useful.
> I do not think reporting back _anything_ other than "ok" adds much
> value
> at all. Sure, if the update hook did something funky you would get
> such
> a report, but the situation is not any different if some warm body is
> sitting on the other end and building on top of what you pushed
> immediately he sees any push into the repository, and in such a case
> your git-push would not get any such reporting anyway.
I disagree that it's the same. In this case the updated ref happens as
a component of the push operation (which of course includes running
update hooks and at the very least looking at their exit codes to see
if a change should be rejected), not as a result of some other process
that happens to occur at nearly the same time. Reporting back the new
ref, at the very least, tells you that it's not useful to update the
tracking ref since it's 100% guaranteed to be wrong by the time the
push finishes.
> We do not even have to worry about this reporting at all if we do not
> allow munging the refs in the update hook. In a sense, this patch is
> creating a problem that does not need to be solved. Perhaps modifying
> update hook to allow so makes it possible to munge refs while
> holding a
> lock, but is it really worth this hassle? Isn't there a better way, I
> wonder?
If there is, I'm happy to hear it; for me this patch is a means, not
an end. What I actually want is to be able to have a particular set of
branches in a particular git repository be as-transparent-as-possible
conduits to corresponding branches in an svn repository.
I arrived at this approach by following this train of thought:
1. The update hook is the only hook that allows me to reject the push,
which I need to do if svn refuses to accept the change.
2. To tell whether svn accepts a change, I need to run git-svn
dcommit; thanks to #1, I need to do that from inside the update hook.
3. When I commit, git-svn needs to track that the git revision now
corresponds to an svn revision. It does that by modifying the commit
message to add its git-svn-id: line.
4. Modifying the commit comment causes the revision's SHA1 to change.
5. Out-of-the-box push thinks a push has failed if the ref's SHA1
changes in the update hook.
6. Therefore push needs to be modified to not do that.
If any one of #1-5 wasn't true or was solvable in a different way,
then #6 wouldn't be needed. For example, if git-svn kept its mapping
of git revisions to svn revisions somewhere else it could leave the
commit messages untouched, meaning the SHA1s wouldn't change.
-Steve
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Jan Hudec @ 2007-11-29 6:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0711282345500.27959@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Wed, Nov 28, 2007 at 23:48:12 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 29 Nov 2007, Jan Hudec wrote:
>
> > On Wed, Nov 28, 2007 at 12:32:10 +0000, Johannes Schindelin wrote:
> > > On Wed, 28 Nov 2007, Jakub Narebski wrote:
> > > > 4. If git-gui would use other language/toolkit, would you
> > > > contribute?
> > > > Yes/No
> > >
> > > Yes, as long as it is a language/toolkit that is available on all
> > > platforms that I (have to) work. That pretty much excludes C# and
> > > Python as a language.
> >
> > Out of interest, where does neither of those two work and Qt and tcl/tk do?
> > Mono and python both seem to be quite portable.
>
> IRIX (an ancient one).
>
> Besides, Mono is darned slow. Even Tcl/Tk is faster.
On the shootout Mono seems to be an order of magnitude faster in most tests.
But maybe they are performing very poorly on some strange platform where they
don't have JIT.
> Furthermore, my complaint was not about a platform where neither C# nor
> Python work. That is irrelevant. If you have one platform where only one
> works, and another platform where only the other works, you cannot have a
> single program for both platforms. Right?
Right.
I probably shouldn't be surprised that mono does not work on older unices,
but I am a bit surprised python does not.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] scripts: do not get confused with HEAD in work tree
From: Mike Hommey @ 2007-11-29 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq9d29h3.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 28, 2007 at 04:15:04PM -0800, Junio C Hamano wrote:
> When you have a file called HEAD in your work tree, many commands that
> our scripts feed "HEAD" to would complain about the rev vs path
> ambiguity. A solution is to form command line more carefully by
> appending -- to them, which makes it clear that we mean HEAD rev not
> HEAD file.
Shouldn't this be done for anything else, then ? You could have a file
with the same name as a branch and have some commands using branch names
fail too.
Mike
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Jan Hudec @ 2007-11-29 7:17 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jakub Narebski, git
In-Reply-To: <200711290248.23239.robin.rosenberg.lists@dewire.com>
On Thu, Nov 29, 2007 at 02:48:22 +0100, Robin Rosenberg wrote:
> I did start doing this so here's my version (pre-msysgit). Please try to bring up the defintion
> of "atomic" again with the author. I did complain a little but nothing happened. The issue is
> that Clearcase is listed as having "atomic" commits which is not true for any usable definition
> of atomic in SCM context. With the definition in use there I think CVS should be considered
> having atomic commits too, at least I've never seen a half-committed file there.
Actually, I did. Or rather, I did see a commit, that didn't make it to the
server, but the client thought it did!
Maybe instead of asking the author to change the definition of atomic, ask
him to add an item for whole-tree commits. That more precisely describes what
is the point.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Sixt @ 2007-11-29 7:39 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Johannes Schindelin, Wincent Colaiuta,
Benoit Sigoure, Git Mailing List
In-Reply-To: <85sl2q6kyu.fsf@lola.goethe.zz>
David Kastrup schrieb:
> Junio C Hamano <gitster@pobox.com> writes:
>> I thought somebody already mention that ash mishandles "export VAR=VAL"
>> but otherwise Ok.
>
> dak@lola:~$ ash
> $ export JUNK=woozle
> $ sh -c 'echo $JUNK'
> woozle
> $ exit
> dak@lola:~$ dash
> $ export JUNK=woozle
> $ sh -c 'echo $JUNK'
> woozle
> $ exit
>
> What problem are we talking about exactly, and with what shell?
$ export foo="bar baz"
$ bash
bash$ export JUNK=$foo
bash$ sh -c 'echo "$JUNK"'
bar baz
bash$ exit
exit
$ ash
ash$ export JUNK=$foo
ash$ sh -c 'echo "$JUNK"'
bar
ash$ exit
The problem is $foo not being quoted on the RHS of the assignment of the
export command: bash doesn't word-split, but ash does. Hence, *if*
export VAR=VAL is used, always quote VAL.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-svn now reads settings even if called in subdirectory
From: Eric Wong @ 2007-11-29 7:41 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git, gitster
In-Reply-To: <1195912076-3903-1-git-send-email-hendeby@isy.liu.se>
Gustaf Hendeby <hendeby@isy.liu.se> wrote:
> Previously, git-svn first read the .git/config file for settings as if
> current working directory was the repository top-directory, and after
> that made sure to cd into top-directory. The result was a silent
> failur to read configuration settings. This patch changes the order
> these two things are done.
>
> Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
>
> ---
>
> This fix seems a bit too obvious, which makes me think I missed
> something conceptual here. However, the patch passes "make test" and
> "make full-svn-test", and the problems I had with the svn.authorsfile
> setting not being honored while fetching from a subdirectory are gone.
Thanks Gustaf,
Seems right to me (note: I never use the authors file feature myself).
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: git-svn rebase issues (the commiter gets changed)
From: Eric Wong @ 2007-11-29 7:52 UTC (permalink / raw)
To: Kelvie Wong; +Cc: git
In-Reply-To: <94ccbe710711220815j663d22e0v3c744244d0a87b66@mail.gmail.com>
Kelvie Wong <kelvie@ieee.org> wrote:
> When using git-svn rebase (I'm not sure if this happens with a regular
> rebase as well, I use use git-svn primarily at work), the following
> oddity happens:
>
> kelvie@mudd (working) qt $ git-cat-file commit
> c27e6207c9078d4225288d55454d6577f0135c16
> tree 13d9ef9cc67f5e6381d7697e5794c0ab5f72c729
> parent b9eb187d3029c5f9a816cb8f5473d9b239952d53
> author kwong <kwong@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195596864 +0000
> committer cscrimgeour
> <cscrimgeour@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195691944 +0000
This is strange. Does this commit end below? or did you truncate
the git-svn-id: line from this message?
>
> Qt/FME Extensions: QFMEDialog/QFMEWizard -> Windows only, for now
>
> This is also a reapplication of r39657, which got rolled back.
>
> These have dependencies on QWinWidget (which is a part of the MFC/Qt Migration
> Solution), and thus, it does not build without it.
> <kw>
> kelvie@mudd (working) qt $ git-cat-file commit
> 7075991c67c6d409ec2315dfeef6f45dd328485b
> tree 13d9ef9cc67f5e6381d7697e5794c0ab5f72c729
> parent b9eb187d3029c5f9a816cb8f5473d9b239952d53
> author kwong <kwong@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195596864 +0000
> committer Kelvie Wong <Kelvie.Wong@safe.com> 1195747291 +0000
This commit hasn't made it into SVN, yet, right? If so, then that's
alright.
>
> Qt/FME Extensions: QFMEDialog/QFMEWizard -> Windows only, for now
>
> This is also a reapplication of r39657, which got rolled back.
>
> These have dependencies on QWinWidget (which is a part of the MFC/Qt Migration
> Solution), and thus, it does not build without it.
> <kw>
>
>
> These are both the exact same commit (the tree, parent, and author are
> equivalent).
>
> Sometimes (not always), the committer in a commit changes to be the
> committer of the parent (svn) commit. This only happens to the
> commits whose parent is the SVN commit. In the above example,
> cscrimgeour is a SVN user, who obviously could not have changed my
> code; the proper commit is the one at the bottom.
>
> Both of these are the first local commit that I have rebased onto SVN.
Did you get these commits by cherry-picking (or format-patch + am)
from another SVN branch? Have these commits been made to SVN already?
`gitk --reflog --all' may reveal some answers or clarify
things for you (assuming you have reflogs enabled in .git/config).
Rebase (all forms of it) *does* rewrite committer info, but how you got
cscrimgeour in there is very strange to me.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: add support for pulling author from From: and Signed-off-by:
From: Eric Wong @ 2007-11-29 7:55 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <1195739082.0@pinky>
Andy Whitcroft <apw@shadowen.org> wrote:
>
> Add support for pulling the real author of a commit from the From:
> and first Signed-off-by: fields of the SVN commit message.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
A minor whitespace fix with an Acked patch below. Thanks.
> ---
> git-svn.perl | 36 +++++++++++++++++++++++++++++-------
> 1 files changed, 29 insertions(+), 7 deletions(-)
> diff --git a/git-svn.perl b/git-svn.perl
> index 5b1deea..a99982d 100755
> @@ -2165,7 +2173,16 @@ sub make_log_entry {
> $log_entry{log} .= "\n";
> my $author = $log_entry{author} = check_author($log_entry{author});
> my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
> - : ($author, undef);
> + : ($author, undef);
> +
> + my ($commit_name, $commit_email) = ($name, $email);
> + if ($_use_log_author) {
> + if ($log_entry{log} =~ /From:\s+(.*?)\s+<(.*)>\s*\n/) {
> + ($name, $email) = ($1, $2);
> + } elsif ($log_entry{log} =~ /Signed-off-by:\s+(.*?)\s+<(.*)>\s*\n/) {
> + ($name, $email) = ($1, $2);
> + }
> + }
> if (defined $headrev && $self->use_svm_props) {
> if ($self->rewrite_root) {
> die "Can't have both 'useSvmProps' and 'rewriteRoot' ",
>From 40fb9135d644f3a1fc47ae9b94ad62ec52b1234b Mon Sep 17 00:00:00 2001
From: Andy Whitcroft <apw@shadowen.org>
Date: Thu, 22 Nov 2007 13:44:42 +0000
Subject: [PATCH] git-svn: add support for pulling author from From: and Signed-off-by:
Add support for pulling the real author of a commit from the From:
and first Signed-off-by: fields of the SVN commit message.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 37 ++++++++++++++++++++++++++++++-------
1 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 640a45a..61f0c1a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -81,6 +81,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'quiet|q' => \$_q,
'repack-flags|repack-args|repack-opts=s' =>
\$Git::SVN::_repack_flags,
+ 'use-log-author' => \$Git::SVN::_use_log_author,
%remote_opts );
my ($_trunk, $_tags, $_branches, $_stdlayout);
@@ -1220,7 +1221,8 @@ use strict;
use warnings;
use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
$_repack $_repack_flags $_use_svm_props $_head
- $_use_svnsync_props $no_reuse_existing $_minimize_url/;
+ $_use_svnsync_props $no_reuse_existing $_minimize_url
+ $_use_log_author/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
use File::Copy qw/copy/;
@@ -2060,11 +2062,17 @@ sub do_git_commit {
croak "$log_entry->{revision} = $c already exists! ",
"Why are we refetching it?\n";
}
- $ENV{GIT_AUTHOR_NAME} = $ENV{GIT_COMMITTER_NAME} = $log_entry->{name};
- $ENV{GIT_AUTHOR_EMAIL} = $ENV{GIT_COMMITTER_EMAIL} =
- $log_entry->{email};
+ $ENV{GIT_AUTHOR_NAME} = $log_entry->{name};
+ $ENV{GIT_AUTHOR_EMAIL} = $log_entry->{email};
$ENV{GIT_AUTHOR_DATE} = $ENV{GIT_COMMITTER_DATE} = $log_entry->{date};
+ $ENV{GIT_COMMITTER_NAME} = (defined $log_entry->{commit_name})
+ ? $log_entry->{commit_name}
+ : $log_entry->{name};
+ $ENV{GIT_COMMITTER_EMAIL} = (defined $log_entry->{commit_email})
+ ? $log_entry->{commit_email}
+ : $log_entry->{email};
+
my $tree = $log_entry->{tree};
if (!defined $tree) {
$tree = $self->tmp_index_do(sub {
@@ -2352,7 +2360,17 @@ sub make_log_entry {
$log_entry{log} .= "\n";
my $author = $log_entry{author} = check_author($log_entry{author});
my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
- : ($author, undef);
+ : ($author, undef);
+
+ my ($commit_name, $commit_email) = ($name, $email);
+ if ($_use_log_author) {
+ if ($log_entry{log} =~ /From:\s+(.*?)\s+<(.*)>\s*\n/) {
+ ($name, $email) = ($1, $2);
+ } elsif ($log_entry{log} =~
+ /Signed-off-by:\s+(.*?)\s+<(.*)>\s*\n/) {
+ ($name, $email) = ($1, $2);
+ }
+ }
if (defined $headrev && $self->use_svm_props) {
if ($self->rewrite_root) {
die "Can't have both 'useSvmProps' and 'rewriteRoot' ",
@@ -2375,23 +2393,28 @@ sub make_log_entry {
remove_username($full_url);
$log_entry{metadata} = "$full_url\@$r $uuid";
$log_entry{svm_revision} = $r;
- $email ||= "$author\@$uuid"
+ $email ||= "$author\@$uuid";
+ $commit_email ||= "$author\@$uuid";
} elsif ($self->use_svnsync_props) {
my $full_url = $self->svnsync->{url};
$full_url .= "/$self->{path}" if length $self->{path};
remove_username($full_url);
my $uuid = $self->svnsync->{uuid};
$log_entry{metadata} = "$full_url\@$rev $uuid";
- $email ||= "$author\@$uuid"
+ $email ||= "$author\@$uuid";
+ $commit_email ||= "$author\@$uuid";
} else {
my $url = $self->metadata_url;
remove_username($url);
$log_entry{metadata} = "$url\@$rev " .
$self->ra->get_uuid;
$email ||= "$author\@" . $self->ra->get_uuid;
+ $commit_email ||= "$author\@" . $self->ra->get_uuid;
}
$log_entry{name} = $name;
$log_entry{email} = $email;
+ $log_entry{commit_name} = $commit_name;
+ $log_entry{commit_email} = $commit_email;
\%log_entry;
}
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] git-svn: Remove unnecessary Git::SVN::Util package
From: Eric Wong @ 2007-11-29 8:01 UTC (permalink / raw)
To: David D. Kilzer; +Cc: ask, git
In-Reply-To: <1195759080-20132-1-git-send-email-ddkilzer@kilzer.net>
"David D. Kilzer" <ddkilzer@kilzer.net> wrote:
> Digest::MD5 is loaded regardless of the package in which it's
> declared, so move its 'use' statement and the md5sum() function
> into the main package.
>
> Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
>
> Ask Bjørn Hansen <ask@develooper.com> wrote:
> > On Nov 21, 2007, at 11:57, David D. Kilzer wrote:
> > > Created new Git::SVN::Util package with an md5sum() function. A
> > > new package was created so that Digest::MD5 did not have to be
> > > loaded in the main package.
> > Huh? It's all in the same file anyway, so what difference does it
> > make?
>
> None!
I have floated the idea of splitting git-svn into several files to make
it easier to maintain and navigate. However, I'm not looking foward to
doing a install system for that...
Maybe it'll just cat all the files together during build and
still install as one file... *shrug*
> git-svn.perl | 23 +++++++++--------------
> 1 files changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 62801c8..17d3020 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -35,6 +35,7 @@ push @Git::SVN::Ra::ISA, 'SVN::Ra';
> push @SVN::Git::Editor::ISA, 'SVN::Delta::Editor';
> push @SVN::Git::Fetcher::ISA, 'SVN::Delta::Editor';
> use Carp qw/croak/;
> +use Digest::MD5;
> use IO::File qw//;
> use File::Basename qw/dirname basename/;
> use File::Path qw/mkpath/;
> @@ -48,8 +49,7 @@ BEGIN {
> foreach (qw/command command_oneline command_noisy command_output_pipe
> command_input_pipe command_close_pipe/) {
> for my $package ( qw(SVN::Git::Editor SVN::Git::Fetcher
> - Git::SVN::Migration Git::SVN::Log Git::SVN
> - Git::SVN::Util),
> + Git::SVN::Migration Git::SVN::Log Git::SVN),
> __PACKAGE__) {
> *{"${package}::$_"} = \&{"Git::$_"};
> }
> @@ -835,19 +835,19 @@ sub cmd_info {
> command_output_pipe(qw(cat-file blob), "HEAD:$path");
> if ($file_type eq "link") {
> my $file_name = <$fh>;
> - $checksum = Git::SVN::Util::md5sum("link $file_name");
> + $checksum = md5sum("link $file_name");
> } else {
> - $checksum = Git::SVN::Util::md5sum($fh);
> + $checksum = md5sum($fh);
> }
> command_close_pipe($fh, $ctx);
> } elsif ($file_type eq "link") {
> my $file_name =
> command(qw(cat-file blob), "HEAD:$path");
> $checksum =
> - Git::SVN::Util::md5sum("link " . $file_name);
> + md5sum("link " . $file_name);
> } else {
> open FILE, "<", $path or die $!;
> - $checksum = Git::SVN::Util::md5sum(\*FILE);
> + $checksum = md5sum(\*FILE);
> close FILE or die $!;
> }
> $result .= "Checksum: " . $checksum . "\n";
> @@ -1187,11 +1187,6 @@ sub find_file_type_and_diff_status {
> return ("file", $diff_status);
> }
>
> -package Git::SVN::Util;
> -use strict;
> -use warnings;
> -use Digest::MD5;
> -
> sub md5sum {
> my $arg = shift;
> my $ref = ref $arg;
> @@ -2926,7 +2921,7 @@ sub apply_textdelta {
>
> if (defined $exp) {
> seek $base, 0, 0 or croak $!;
> - my $got = Git::SVN::Util::md5sum($base);
> + my $got = ::md5sum($base);
> die "Checksum mismatch: $fb->{path} $fb->{blob}\n",
> "expected: $exp\n",
> " got: $got\n" if ($got ne $exp);
> @@ -2945,7 +2940,7 @@ sub close_file {
> if (my $fh = $fb->{fh}) {
> if (defined $exp) {
> seek($fh, 0, 0) or croak $!;
> - my $got = Git::SVN::Util::md5sum($fh);
> + my $got = ::md5sum($fh);
> if ($got ne $exp) {
> die "Checksum mismatch: $path\n",
> "expected: $exp\n got: $got\n";
> @@ -3300,7 +3295,7 @@ sub chg_file {
> $fh->flush == 0 or croak $!;
> seek $fh, 0, 0 or croak $!;
>
> - my $exp = Git::SVN::Util::md5sum($fh);
> + my $exp = ::md5sum($fh);
> seek $fh, 0, 0 or croak $!;
>
> my $pool = SVN::Pool->new;
> --
> 1.5.3.4
>
> -
> 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
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: add a show-externals command.
From: Eric Wong @ 2007-11-29 8:04 UTC (permalink / raw)
To: Vineet Kumar; +Cc: git
In-Reply-To: <1195512975-3647-1-git-send-email-vineet@doorstop.net>
Vineet Kumar <vineet@doorstop.net> wrote:
> show-externals can be used by scripts to provide svn:externals-like
> functionality. For example, a script can list all of the externals and then
> use check out the listed URLs at the appropriate paths, similar to what the svn
> client does. Said script (or perhaps git-svn itself, in the future) could
> simply invoke svn export on the paths, or it could go one further, using
> git-svn clone and even git-submodule together to better integrate externals
> checkouts.
>
> The implementation is shamelessly copied from show-ignores. A more general
> command to list user-specified properties is probably a better idea.
>
> Signed-off-by: Vineet Kumar <vineet@doorstop.net>
Thanks.
Acked-by: Eric Wong <normalperson@yhbt.net>
I'm close to having svn:externals supported in git-svn, too. But
previously cloned repositories probably won't support them
out-of-the-box, so this can still be useful.
> ---
> git-svn.perl | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 5b1deea..74966ed 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -141,6 +141,9 @@ my %cmd = (
> 'show-ignore' => [ \&cmd_show_ignore, "Show svn:ignore listings",
> { 'revision|r=i' => \$_revision
> } ],
> + 'show-externals' => [ \&cmd_show_externals, "Show svn:externals listings",
> + { 'revision|r=i' => \$_revision
> + } ],
> 'multi-fetch' => [ \&cmd_multi_fetch,
> "Deprecated alias for $0 fetch --all",
> { 'revision|r=s' => \$_revision, %fc_opts } ],
> @@ -560,6 +563,21 @@ sub cmd_show_ignore {
> });
> }
>
> +sub cmd_show_externals {
> + my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
> + $gs ||= Git::SVN->new;
> + my $r = (defined $_revision ? $_revision : $gs->ra->get_latest_revnum);
> + $gs->prop_walk($gs->{path}, $r, sub {
> + my ($gs, $path, $props) = @_;
> + print STDOUT "\n# $path\n";
> + my $s = $props->{'svn:externals'} or return;
> + $s =~ s/[\r\n]+/\n/g;
> + chomp $s;
> + $s =~ s#^#$path#gm;
> + print STDOUT "$s\n";
> + });
> +}
> +
> sub cmd_create_ignore {
> my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
> $gs ||= Git::SVN->new;
> --
> 1.5.3.4
>
> -
> 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
--
Eric Wong
^ permalink raw reply
* Re: git-svn: surprising behaviors/bugs?
From: Eric Wong @ 2007-11-29 8:10 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git
In-Reply-To: <bf7b2dda0711220537h3f37c84ag899b74daa9a8fe1f@mail.gmail.com>
Gustaf Hendeby <hendeby@gmail.com> wrote:
> I've been running git for most my stuff for some time now, and am
> really pleased with what it has to offer. However, all my coworkers
> aren't gitified yet, and therefore I sometimes have to work with svn.
> I've learned to appreciate git-svn for this, since it lets me utilize
> the strengths of git and still allows for my coworkers to think I use
> their svn setup. Thanks to all who contribute to this wonderful
> tools!
>
> In my work with git-svn I have stumbled upon the following two
> unexpected behaviors. Basically, am I doing/understanding something
> wrong, or is this buggy behavior in git-svn? (I'm presently using git
> 1.5.3.6, but have been experiencing these things for a while.)
>
>
> 1. I don't really like svn's committer info, so I got an authorsfile
> set. This works great when I'm fetching/dcommitting from the
> top-directory in my git checkout (the one with .git in), however, if
> I'm in a subdirectory the authorsfile doesn't kick in and I get the
> svn commiter info. This is not a big deal, but a bit surprising and
> my history gets a bit ugly.
I see you've already fixed that. Thanks.
> 2. My second problem involves getting the support in git-svn for tags
> and branches to work. Having a standard layout of the svn repository,
> in this case
> /source/project/(trunk|branch|tags)
> svn clone -s only works as expected sometimes. Sometimes I only get
> the revision history, not including any actual content (ie none files
> of the files under control turns up in git) from the clone. When I
> get this problem I usually clone the trunk only, and add tags myself.
> This is far from optimal, and also error prone. Other times, the
> clone works as expected and gives me the tags and branches and all the
> content.
Any chance there's a BOFH at the other end playing around with
permissions while you were testing?
> I think the problem occurs when I'm not the owner of the svn
> repository, and only have access (read/write) to the
> project/(trunk|branch|tag) part, and don't have any access at all to
> source. Ie, svn ls works for /source/project and
> /source/project/trunk etc, but not /source (where I returns 403
> Forbidden access). All svn access is through a svn-server that I
> can't control myself.
I'll have to look into that some other time.
Does `svn log -v' work for /source/project ?
Am I correct in what you have is currently like this?
[svn-remote "svn"]
url = http://domain/
branches = source/project/branches/*:refs/remotes/*
tags = source/project/tags/*:refs/remotes/tags/*
fetch = source/project/trunk:refs/remotes/trunk
If so, can you change it to something like this?
[svn-remote "svn"]
url = http://domain/source/project
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
fetch = trunk:refs/remotes/trunk
And see if that works all the time?
Thanks,
--
Eric Wong
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johan Herland @ 2007-11-29 8:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Nicolas Pitre, J. Bruce Fields, Johannes Schindelin,
しらいしななこ ,
Andreas Ericsson, Jakub Narebski
In-Reply-To: <7vlk8hzx0g.fsf@gitster.siamese.dyndns.org>
On Thursday 29 November 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > ... In all the tutorials for $job I've done so
> > far, I simply never talk about pull nor clone, but rather about init,
> > "git remote", fetch and merge, with explicit and meaningful branch
> > names. I think that basic commands, even if there is a bit more of
> > them, make Git easier to learn and understand than talking about those
> > magic meta commands hiding the truth away.
>
> That's actually a quite interesting approach for teaching.
>
> The original "tutorial" (now core-tutorial) was similar in spirit; it
> built the user experience by starting at sequence of low level commands,
> and then finally said "since this is so often used combination, there is
> a short-hand for it that does all". I think the approach would work
> quite well for people who want to use the tool with deep understanding.
>
> However, I am not so sure about people who just want canned set of
> instructions and follow them blindly to get their work done. And I do
> not think the latter classes of users are necessarily wrong.
>
> Such a canned set of instructions would (if the project that supplies
> the cheat-sheet encourages merges instead of rebases) talk about "clone
> then commit then push then pull and repeat", without mentioning what
> pull does is fetch+merge nor what fetch means and what merge means, and
> that would let people get started without deeper understanding.
>
> But the lack of deeper understanding would hurt them in the longer run
> (e.g. "my push was rejected with something called non-fast-forward ---
> what does that mean and what would I do now?").
What about ending the cheat-sheet with a big fat link to a FAQ? The FAQ
answers common questions like the above (resulting from the cheat-sheet
glossing over the details) with links to appropriate sections in the more
thorough introduction (core-tutorial), explaining what's _really_ going on.
Just a thought.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Andreas Ericsson @ 2007-11-29 8:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, J. Bruce Fields, Lars Hjemli, Steven Grimm,
Linus Torvalds, git
In-Reply-To: <7v1waa2bfi.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> So my rationale was: if we already have an existing framework to integrate
>> remote changes with our current branch, why not just go ahead and use it?
>> That's the reason BTW why I originally wanted a "rebase" merge stragegy.
>> Even if it is not technically a merge.
>>
>> I really rather have no user-friendly support for fetch+rebase (and utter
>> a friendly, but loud curse everytime I made a "git pull" by mistake) than
>> yet another command.
>
> I suspect that people who do not like the two modes of checkout will
> certainly not appreciate the overloading two behaviours to create
> different kind of histories and two different ways to continue when the
> integration do not go smoothly upon conflicts these two behaviours have.
>
> However, I agree very much with an earlier comment made by Daniel about
> our UI being task oriented instead of being command oriented, and I
> actually consider it a good thing. So it does not bother me too much
> that "git pull --rebase" has a quite different workflow from the regular
> "merge" kind of pull.
>
> So let's queue "pull --rebase" and see what happens.
>
I've used the --rebase option to git pull, explained it to my co-workers
and also made sure they're using a version of git that has it. So far
there hasn't been a single complaint about "git pull" being any harder
to grok.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rollback of git commands
From: Karl Hasselström @ 2007-11-29 8:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jon Smirl, Sean, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0711281125320.9605@xanadu.home>
On 2007-11-28 11:26:45 -0500, Nicolas Pitre wrote:
> On Wed, 28 Nov 2007, Jon Smirl wrote:
>
> > The state contained in the other config files in .git/* is not
> > getting check pointed. I can use reflog to move my branch heads
> > around. But doing that does not undo the changes to the state
> > recorded in .git/*. After the error I encountered I moved my
> > branch head back, but the state stgit had stored in .git/* was out
> > of sync with where the branch had been moved to.
>
> It's up to stgit to version control its state then. It may even use
> a reflog for it. All the machinery is there already.
I agree -- this is StGit's job.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/3] Add basic cvsimport tests
From: Andreas Ericsson @ 2007-11-29 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Emanuele Giaquinta, git
In-Reply-To: <7v8x4i3tn4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> + cat <<EOF >o_fortuna &&
>> +O Fortuna
>> + ...
>
> Copyrights?
>
>> +add "O Fortuna" lyrics
>> +
>> +These public domain lyrics make an excellent sample text.
>> +EOF
>
> Ah, really? Ok...
The poet, whoever he/she was (no-one knows today), has been dead
nearly 800 years, so any copyrights that might once have been in
place have expired.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rollback of git commands
From: Theodore Tso @ 2007-11-29 8:28 UTC (permalink / raw)
To: Jon Smirl
Cc: Daniel Barkalow, Karl Hasselström, Junio C Hamano,
Git Mailing List
In-Reply-To: <9e4733910711281542r5b1e5dd9o68ff8565f9000453@mail.gmail.com>
On Wed, Nov 28, 2007 at 06:42:56PM -0500, Jon Smirl wrote:
> I'm a patch developer. You need to change the patches continuously to
> track feedback on the lkml type lists. You also have to rebase in
> order to keep tracking head. Other people often work on the same
> things and this triggers merges against the pending patches.
Yeah, I use guilt for projects where I have a patch queue that takes a
while to merge into the mainline, due to quality control or review
guidelines that still need to be met. Basically the kernel has a
different workflow than git, where each project or developer has a
separate patch queue that is maintained inside git (possibly with
guilt or stgit as helpers) or quilt, instead of a centrally managed pu
branch. This is I suspect mainly a scaling issue; it's hard to keep a
centrally maintained pu branch because anytime someone wants to make a
change to one of their topic branches, they have to go through the
central maintainer. The closest analogue to the pu branch is Andrew
Morton's akpm, and he gets grumpy when there are merge conflicts
between the various branches and patch queues that he pulls from in
order to make the -mm tree for integration testing.
> I'd just like for stgit to become a core part of git so that is can be
> made more bullet proof. I'm losing my patch stack every couple of
> weeks. It's normally a "user error" but it is way to easy to make
> these user errors.
I haven't tried using stgit in quite a while mainly because I was
finding it too easy to lose my patch queue. It was happening to me
*way* to often, and while it sounds like it's gotten better due to
adding more sanity checks --- and when I tried it last, "stg repair"
didn't exist --- it sounds like it is still possible for someone who
typo's a command to get themselves into trouble. I'm sure it's not an
issue for the stgit developers because they know which commands to
avoid, but if something isn't 100% bulletproof --- I get nervous.
So my solution to this problem is I use guilt. I *like* the fact that
the primary storage mechanism is actual flat ASCII patch files, since
as a result I've never lost a patch stack --- ASCII patch files are
much more robust. My way of rebasing a set of patches is very simple;
I just do "guilt pop -a; git merge master; guilt push -a" --- and if
there are any conflicts, then I do a "guilt push -f", fix up the
conflicts, follow it with a "guilt refresh", and then resume pushing
the rest of my patches sing "guilt push -a". It just works; no muss,
no fuss, no dirty dishes.
Another thing this allows me to do is that it is possible to put the
guilt patch stack itself under git control. This allows me to go
backwards in time and see what the patch stack looked like n days or n
weeks ago. A comment in the patch header indicates what version of
the kernel the patch stack was meant against.
For example for ext4 development the guilt patch stack is themselves
stored using git on repo.or.cz, with multiple people having access to
push updates to the patch queue. Before I start hacking the ext4,
I'll do run the command "(cd .git/patches/ext4dev; git pull") to check
for new updates in the ext4 patch queue, and if it has changed, I'll
do a "guilt pop -a; guilt push -a" to refresh the working directory
and ext4dev branch in my Linux git tree. When I'm done making
changes, by using commands such as "guilt pop", "guilt refresh",
"guilt pop", et. al., I'll commit changes in the .git/patches/ext4dev
tree, and then push them back to repo.or.cz.
We also have a system where an automated build/test server checks
every few hours if the patch queue on repo.or.cz has changed, and if
so, it pulls the patch queue, and then builds and tests the patch
queue on a wide variety of hardware architectures (i386, x86_64, ia64,
ppc64, s390, etc.) and sends an e-mail pack to the developers list
telling us which test hardware platforms passed, and which platforms
fail. Actually, we do two such tests --- one up to the "stable" point
in the patch series, which represents the next set of patches we plan
to push to Linus during the next merge window, and one for the entire
patch queue (stable plus unstable patches that need more work).
It works quite well for us --- and while there are some advanced
feature that stgit has which guilt doesn't, the feeling of safety of
knowing that the ASCII patch files won't get lost, and the ability to
do things such as shared patch queue maintenance and ability to keep
the patch queue under SCM are enough of a win that at least for my
purposes guilt is the better choice.
> stgit is what you need for this work flow. It lets me easily rebase or
> edit specific patches. It also lets me easily maintain private debug
> patches that I can apply as needed.
As mentioned above, I use guilt for major patch queues. For smaller
sets of patches, such as private debug patches, I just use a separate
git branch for those, and keep them up-to-date by using "git rebase"
and "git rebase -i". Then when I want to enable some debug patch,
I'll just do a "git merge" in a scratch branch.
- Ted
^ permalink raw reply
* Re: [PATCH] rebase -i: give rerere a chance
From: David Kastrup @ 2007-11-29 9:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711290021280.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 28 Nov 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > @@ -166,13 +167,13 @@ pick_one_preserving_merges () {
>> > msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
>> > # No point in merging the first parent, that's HEAD
>> > new_parents=${new_parents# $first_parent}
>> > - # NEEDSWORK: give rerere a chance
>> > if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
>> > GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
>> > GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
>> > output git merge $STRATEGY -m "$msg" \
>> > $new_parents
>> > then
>> > + git rerere
>>
>> This comment is not about this rerere change, but output is a shell
>> function and I vaguely recall we had a discussion on "VAR=VAL cmd" form
>> of single-shot export not working for them as expected...
>
> Hmm. What do you propose? In the long run, I _want_ to have rebase as a
> builtin, which would solve this problem, probably. But in the short run?
Well, something like
if ! ( GIT_xxx=A; export GIT_xxx; output git merge ... )
should likely work.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-svn: surprising behaviors/bugs?
From: Gustaf Hendeby @ 2007-11-29 9:59 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20071129081031.GF32277@soma>
On Nov 29, 2007 9:10 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Gustaf Hendeby <hendeby@gmail.com> wrote:
> > 1. I don't really like svn's committer info, so I got an authorsfile
> > set. This works great when I'm fetching/dcommitting from the
> > top-directory in my git checkout (the one with .git in), however, if
> > I'm in a subdirectory the authorsfile doesn't kick in and I get the
> > svn commiter info. This is not a big deal, but a bit surprising and
> > my history gets a bit ugly.
>
> I see you've already fixed that. Thanks.
Yes, it turned out to be easier than I thought. The fix indicates
that other options are lost as well, but I don't know how to test for
that or it would have been easier for others to verify the problem.
> > 2. My second problem involves getting the support in git-svn for tags
> > and branches to work. Having a standard layout of the svn repository,
> > in this case
> > /source/project/(trunk|branch|tags)
> > svn clone -s only works as expected sometimes. Sometimes I only get
> > the revision history, not including any actual content (ie none files
> > of the files under control turns up in git) from the clone. When I
> > get this problem I usually clone the trunk only, and add tags myself.
> > This is far from optimal, and also error prone. Other times, the
> > clone works as expected and gives me the tags and branches and all the
> > content.
>
> Any chance there's a BOFH at the other end playing around with
> permissions while you were testing?
This time I think BOFH is innocent, unless for maybe setting up the
SVN repository in a stupid way.
> > I think the problem occurs when I'm not the owner of the svn
> > repository, and only have access (read/write) to the
> > project/(trunk|branch|tag) part, and don't have any access at all to
> > source. Ie, svn ls works for /source/project and
> > /source/project/trunk etc, but not /source (where I returns 403
> > Forbidden access). All svn access is through a svn-server that I
> > can't control myself.
>
> I'll have to look into that some other time.
Would be great, thanks, let me know how I can help. I've tried to
answer your questions about the setup below.
>
> Does `svn log -v' work for /source/project ?
Works just fine.
>
> Am I correct in what you have is currently like this?
>
> [svn-remote "svn"]
> url = http://domain/
> branches = source/project/branches/*:refs/remotes/*
> tags = source/project/tags/*:refs/remotes/tags/*
> fetch = source/project/trunk:refs/remotes/trunk
>
>
> If so, can you change it to something like this?
>
> [svn-remote "svn"]
> url = http://domain/source/project
> branches = branches/*:refs/remotes/*
> tags = tags/*:refs/remotes/tags/*
> fetch = trunk:refs/remotes/trunk
>
> And see if that works all the time?
I just made three different setups to get the same (problematic) project.
PLAIN TRUNK (works as expected, but lacks tags/branches)
git svn init https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes.trunk
cd shapes.trunk
git svn fetch # Now gives me the history of the trunk with all content
cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://svn.isy.liu.se/rt/tidefelt/source/shapes/trunk
fetch = :refs/remotes/git-svn
WITH STANDARD LAYOUT (gets no content)
git svn init -s https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes
cd shapes
git svn fetch # No files present in any commit
cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://svn.isy.liu.se/rt
fetch = tidefelt/source/shapes/trunk:refs/remotes/trunk
branches = tidefelt/source/shapes/branches/*:refs/remotes/*
tags = tidefelt/source/shapes/tags/*:refs/remotes/tags/*
What seems to complicate things here, and that I didn't realize
before, is that I have access to https://svn.isy.liu.se/rt (at least
read), so if git-svn starts from the bottom and checks for premissions
it will find this root directory.
WITH CHANGED STANDARD LAYOUT (retrieves neither content nor tags)
git svn init -s https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes.fix
cd shapes.fix
# Edit .git/config
git svn fetch
cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = https://svn.isy.liu.se/rt/tidefelt/source/shapes
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
The version where I make changes in .git/config file fails also for a
project that I don't have any problems with just using the -s option.
Do I have to do anything more than just change the config file?
All of the above git svn fetch complains a bit the first time with a
message similar to:
W: Ignoring error from SVN, path probably does not exist: (175007):
HTTP Path Not Found: REPORT request failed on
'/rt/!svn/bc/100/tidefelt/source/shapes':
'/rt/!svn/bc/100/tidefelt/source/shapes' path not found
Please, let me know if there is any other information that would be useful.
/Gustaf
^ permalink raw reply
* Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: David Kastrup @ 2007-11-29 10:17 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Johannes Schindelin, Wincent Colaiuta,
Benoit Sigoure, Git Mailing List
In-Reply-To: <474E6CC8.8000301@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>> What problem are we talking about exactly, and with what shell?
>
> $ export foo="bar baz"
> $ bash
> bash$ export JUNK=$foo
> bash$ sh -c 'echo "$JUNK"'
> bar baz
> bash$ exit
> exit
> $ ash
> ash$ export JUNK=$foo
> ash$ sh -c 'echo "$JUNK"'
> bar
> ash$ exit
>
> The problem is $foo not being quoted on the RHS of the assignment of
> the export command: bash doesn't word-split, but ash does. Hence, *if*
> export VAR=VAL is used, always quote VAL.
I much prefer the quoting solution over the quite more invasive rewrites
proposed here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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