* Re: Commiting changes onto more than one branch
From: Mike Jarmy @ 2009-11-25 16:47 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580911250838x361ae081n271fcee2d1234703@mail.gmail.com>
On Wed, Nov 25, 2009 at 11:38 AM, Eugene Sajine <euguess@gmail.com> wrote:
>>
>> Suppose that I checkout the v3 branch, and fix the bug by editing
>> several different files. (Lets assume for now that the files in
>> question have not diverged between any of the 3 branches, even though
>> tons of other files have changed). How do I commit the bugfix into
>> all of v3, v4 and v5? Clearly, merging the branches together would be
>> bad. So I think what I should do is perform 3 different commits, but
>> I'm not quite sure how to juggle the git index (or stash or whatever)
>> to accomplish this. This may be a really obvious question, but I'm a
>> confused git newbie.
>
> It as not as clear for me why you think merge will be bad?
> If you commit your changes to the v3, then merging to v4 and v5 (which
> are not changed) should be very simple fast forward merge. Which means
> just move the pointer to the last commit from v3
>
> Am i missing something?
I guess I didn't explain it too well, I made it sound like v3, v4 and
v5 were still more-or-less the same. What I'm thinking about here is
a case where we have switched to git a while back, and then done a lot
of work on the various different branches, so that v3, v4 and v5 have
diverged very far from each other. In that case, we would never want
to merge them together.
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Thomas Rast @ 2009-11-25 16:47 UTC (permalink / raw)
To: Mike Jarmy; +Cc: git
In-Reply-To: <6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com>
Mike Jarmy wrote:
> Suppose that I checkout the v3 branch, and fix the bug by editing
> several different files. (Lets assume for now that the files in
> question have not diverged between any of the 3 branches, even though
> tons of other files have changed). How do I commit the bugfix into
> all of v3, v4 and v5? Clearly, merging the branches together would be
> bad. So I think what I should do is perform 3 different commits, but
> I'm not quite sure how to juggle the git index (or stash or whatever)
> to accomplish this. This may be a really obvious question, but I'm a
> confused git newbie.
You can build the fix on top of the merge-base of v3, v4 and v5, i.e.
git checkout -b myfix $(git merge-base v3 $(git merge-base v4 v5))
# work
git commit
and then merge it to each of the version branches:
for b in v3 v4 v5; do
git checkout $b
git merge myfix
done
So much for the theory. In the model suggested in the gitworkflows(7)
manpage and used in git.git, v3 is contained in v4 and similar for v5.
This means that after merging (possibly several) fixes to v3, you can
merge v3 into v4 and v4 into v5 (and so on, through all versions) to
propagate the fixes.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Jakub Narebski @ 2009-11-25 16:50 UTC (permalink / raw)
To: Mike Jarmy; +Cc: git
In-Reply-To: <6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com>
Mike Jarmy <mjarmy@gmail.com> writes:
> My question is this: How do I manage a checkin for a bugfix that
> affects, say, only branches v3, v4, and v5?
Take a look at "Resolving conflicts/dependencies between topic
branches early" blog post by Junio C Hamano (git maintainer) at
http://gitster.livejournal.com/27297.html
In short the solution is to create separate topic branch for a bugfix,
branching off earliest place where it would be relevant, then merge
this bugfix branch into all development branches you need
(e.g. maint-v3, maint-v4, maint-v5, master).
This means:
$ git checkout -b fix-frobulator--issue-1235 maint-v3
<create commit or series of commits>
$ git checkout maint-v3
$ git merge fix-frobulator--issue-1235
<resolve conflicts if any>
$ git checkout maint-v4
$ git merge fix-frobulator--issue-1235
<resolve conflicts if any>
[...]
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [egit] Git repository with multiple eclipse projects ?
From: Yann Dirson @ 2009-11-25 16:47 UTC (permalink / raw)
To: git
I am investigating whether it is possible at all to have several
eclipse projects in a single git repo, and have those projects
correctly seen as managed by git.
When importing a git repo into eclipse, we get a list of projects to
import, but that list is empty. What is expected by egit to get this
list filled ?
It also does not look like it would be possible to use the "share"
functionnality to setup such a repository from multiple projects (or
from a project set), right ?
Best regards,
--
Yann
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Avery Pennarun @ 2009-11-25 17:38 UTC (permalink / raw)
To: Mike Jarmy; +Cc: Eugene Sajine, git
In-Reply-To: <6b4a562b0911250847x59116687iba1d1640ca6c3887@mail.gmail.com>
On Wed, Nov 25, 2009 at 11:47 AM, Mike Jarmy <mjarmy@gmail.com> wrote:
> I guess I didn't explain it too well, I made it sound like v3, v4 and
> v5 were still more-or-less the same. What I'm thinking about here is
> a case where we have switched to git a while back, and then done a lot
> of work on the various different branches, so that v3, v4 and v5 have
> diverged very far from each other. In that case, we would never want
> to merge them together.
What many people do is, in fact, to merge v3->v4->v5.
This isn't as crazy as it sounds. Once upon a time, v4 was just an
earlier version of v3, right? And when you fix a bug in v3, it was
usually also a bug in v4, right? So in fact, for many projects, it's
safe to say that "after we created v4, all further changes to v3
should be propagated to v4." And likewise from v4 to v5.
In that case, you'd simply do
git checkout v3
# commit your fix
git checkout v4
git merge v3
Now, setting that up in the *first* place can be a bit tricky, since
the way your imported history probably currently works, git doesn't
actually know that the history of v4 is a superset of the history of
v3; it thinks of them as two totally different histories, and merging
from one to the other will be completely disastrous. So you have to
do a bit of setup first
# manually make sure all your required patches from v3 are now in v4.
# just do it the way you used to do it (the hard way)
# now tell git that it's done:
git checkout v4
git merge -s ours v3
After that, future merges from v3 to v4 will be easy (the first set of
steps above) and include only the newer changes.
Note that merging fixes back from v4 to v3 is entirely different,
because you'll *never* want to take *all* the changes from v4 and put
them into v3. The best thing to do is apply them to v3 first, then
merge them into v4, but of course that won't always be how developers
end up doing it. In that case, you can backport them using 'git
cherry-pick' (see the git docs).
Note that using topic branches, as Thomas and Jakub mentioned, is
orthogonal to this method. That is, your problem could be resolved by
doing that, or this, or both. (Although if the histories really are
totally disjoint, you'll still need to do something like the '-s ours'
trick first.) On my own projects, I do a bit of both methods; simple
bugfixes go straight to the earliest relevant release branch, but
bigger changes go on topic branches.
Have fun,
Avery
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Mike Jarmy @ 2009-11-25 17:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m38wdublbq.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Take a look at "Resolving conflicts/dependencies between topic
> branches early" blog post by Junio C Hamano (git maintainer) at
> http://gitster.livejournal.com/27297.html
>
> In short the solution is to create separate topic branch for a bugfix,
> branching off earliest place where it would be relevant, then merge
> this bugfix branch into all development branches you need
> (e.g. maint-v3, maint-v4, maint-v5, master).
Thanks guys. I think some cross between this and the cherry-picking
idea would work for us most of the time, if we go with the workflow
that I originally specified. I like the branch-per-bugfix idea -- its
taking some time for me to free my mind to the point where I grok how
lightweight and flexible branching really is. Just branch off from
the earliest affected release, naming the branch after the bug
('fix-frobulator--issue-1235'). When finished, merge/cherry-pick back
into the various branches.
Thomas's idea of using a more sophisticated workflow has definitely
got me thinking. Back in the day, once we started working on a new
release, say v6, then the other branches to an extent become
mothballed except for bugfixes. In that case, using a merge-base
approach would make sense. More and more though, we have started to
build separate sub-projects on top of specific releases -- in other
words, we are simultaneously making a new product on top of v4, while
preparing to release v5, and getting ready to start work on v6 in
earnest, all the while fixing bugs across mulitple releases going all
the way back to v2. Its getting very complicated :-). And our
current VCS is starting to become an active hindrance in helping us
manage all this in a sane way.
What I'm going to do is set up a toy environment that mirrors what I
hope our final repository will look like. Then I'll play with it for
a while and concoct corner-case scenarios and see how it holds up.
Once I have a workflow that I like, I can demonstrate it to my
colleagues in gitk, and we can think about how to make it better.
Thanks,
Mike Jarmy
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Nicolas Pitre @ 2009-11-25 17:43 UTC (permalink / raw)
To: Mike Jarmy; +Cc: git
In-Reply-To: <6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com>
On Wed, 25 Nov 2009, Mike Jarmy wrote:
> My question is this: How do I manage a checkin for a bugfix that
> affects, say, only branches v3, v4, and v5?
>
> Suppose that I checkout the v3 branch, and fix the bug by editing
> several different files. (Lets assume for now that the files in
> question have not diverged between any of the 3 branches, even though
> tons of other files have changed). How do I commit the bugfix into
> all of v3, v4 and v5? Clearly, merging the branches together would be
> bad. So I think what I should do is perform 3 different commits, but
> I'm not quite sure how to juggle the git index (or stash or whatever)
> to accomplish this. This may be a really obvious question, but I'm a
> confused git newbie.
Besides what other people have already suggested, you might simply elect
to use 'git cherry-pick' on the v4 and v5 branches to copy the fix from
the v3 branch.
> Also, even though I may need to do 3 commits, it would be nice if the
> commits were related together in some way, since in a sense they
> represent only one action (namely, fixing the bug). Is there a way to
> do that, so that its clear in gitk that it was really one unified
> thing?
You can use the -x argument with 'git cherry-pick'. This won't create a
formal history graph but at least the commit log will record a reference
to the original fix.
Nicolas
^ permalink raw reply
* Re: Git repository mesh?
From: Matthieu Moy @ 2009-11-25 18:23 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0911250416u7e363ab2yf9334bad09f957fb@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On 11/25/09, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Then, fetch from all of them and:
>>
>> git log ^HEAD repo1/master repo2/master repo3/master
>
> Very nice. Thanks I did not know about "^HEAD".
Read "not HEAD", this means "remove the ancestry of HEAD in the output".
See "man git-rev-parse" for details.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Avery Pennarun @ 2009-11-25 18:28 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Marc Fournier, git
In-Reply-To: <20091125080812.6117@nanako3.lavabit.com>
On Tue, Nov 24, 2009 at 6:08 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Avery Pennarun <apenwarr@gmail.com>
>
>> Yup. This is basically a bug in "git merge -s subtree": it guesses
>> which subtree to merge into, rather than actually taking a prefix
>> parameter. I've been meaning to either submit a patch for this, or
>> find a way to work around it.
>
> Probably you can save time by using what was already done
>
> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021
Hi Nanako,
I've read through the thread (I do remember skimming it awhile ago)
but can't find patches for the syntax actually under discussion. I
found a patch that introduces "-s theirs", which was summarily shot
down in favour of adding -X support, but I can't find any actual patch
for this. Moreover, git-merge seems to have been ported to C since
then, so I guess it wouldn't apply anyway. And I can't find any
implementation at all for the discussed "-Xsubtree=" option, which I'm
guessing didn't actually ever get done.
Am I missing something? It looks fairly easy to throw in anyway, but
it's even easier if someone has already done it :)
Thanks,
Avery
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Junio C Hamano @ 2009-11-25 18:58 UTC (permalink / raw)
To: Mike Jarmy; +Cc: Eugene Sajine, git
In-Reply-To: <6b4a562b0911250847x59116687iba1d1640ca6c3887@mail.gmail.com>
Mike Jarmy <mjarmy@gmail.com> writes:
> I guess I didn't explain it too well, I made it sound like v3, v4 and
> v5 were still more-or-less the same. What I'm thinking about here is
> a case where we have switched to git a while back, and then done a lot
> of work on the various different branches, so that v3, v4 and v5 have
> diverged very far from each other. In that case, we would never want
> to merge them together.
I take it to mean that even though v[345] have diverged, the area that the
particular change you have in mind has to touch haven't changed since they
forked. Otherwise you wouldn't be able to apply the same change to all of
them in the same form and instead would be making the logically same
change in physically different ways per branch, and you won't be asking
this question.
o--o--o--o--o--o--o--o v4
/
--o--x--x--x--x--x--x--x v3
If you implemented your change at the tip of v3 branch and merge the
result to v4, you will pull _all_ of 'x' into v4 that may not be desirable
if the branches diverged a lot, of course.
o--o--o--o--o--o--o--o-------M v4
/ /
--o--x--x--x--x--x--x--x /
\ /
Y---Y your change(s) == v3
But nobody tells you to do this.
Instead, you can fork such a topic from the latest common.
o--o--o--o--o--o--o--o v4
/
--o--x--x--x--x--x--x--x v3
\
Y---Y
your change(s)
and merging this to v3 and v4 will have the desired effect.
o--o--o--o--o--o--o--o---------M v4
/ /
--o--x--x--x--x--x--x--x---M v3 /
\ / /
Y---Y----------------.-----.
your change(s)
The merges will incorporate this particular change alone without dragging
anything else. When you merge it to v4, none of the unrelated 'x' will be
merged into it.
In general you shouldn't fork a topic from the _tip_ of the oldest branch,
if the branches are not meant to be merged as a whole.
Of course, if this becomes cumbersome, you would adopt a better branch
management to keep the numbers of 'x' that shouldn't be in later branches
to the minimum.
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Junio C Hamano @ 2009-11-25 19:31 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <32541b130911251028h6db240d5yd171fa4941ef14ba@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
>> Probably you can save time by using what was already done
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021
>
> Hi Nanako,
>
> I've read through the thread (I do remember skimming it awhile ago)
> but can't find patches for the syntax actually under discussion.
I very much prefer gmane threading when following discussion over all the
other mail archives, but this shows one thing I really dislike about it.
It is not easy to find a near-by thread when looking at an old article,
and you have to be willing to bisect the page number at the right hand
side of the web UI. Often a patch series is posted as a separate thread
after a discussion reaches conclusion or identifies an issue to solve, and
the real patch series lives in a near-by thread. Very inconvenient.
I don't know how Nana digs up older discussion; maybe she knows better
ways.
In my primary repository, I have an archive of mothballed branches kept
with this alias:
[alias]
hold = "!sh -c 'git update-ref refs/hold/$1 refs/heads/$1 && git branch -D $1' -"
and found this series in there. It applies to v1.6.0-rc0~245 (no, I won't
be rebasing this myself---I don't have time for that while preparing for
the pre-release feature freeze).
f7713ce Document that merge strategies can now take their own options
7eda236 Make "subtree" part more orthogonal to the rest of merge-recursive.
e416d61 Teach git-pull to pass -X<option> to git-merge
09f7d22 Teach git-merge to pass -X<option> to the backend strategy module
904288c git-merge-recursive-{ours,theirs}
e0aafb4 git-merge-file --ours, --theirs
-d3e977b Merge branch 'maint'
Look at http://github.com/gitster/git/commits/jc/merge-theirs/
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 19:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B0D2E19.6020100@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Junio C Hamano venit, vidit, dixit 24.11.2009 09:56:
>> While working inside a deep subdirectory, it sometimes is necessary to
>> find a string you see in a file you are working on from the files in the
>> entire project. This is especially true when you are dipping your toe
>> into an unfamiliar project.
>>
>> By default, "git grep" limits its search space to the current directory
>> and below (i.e. as if "-r ." is specified), and it is rather cumbersome to
>> repeat ../ as many times as necessary. This new option tells "git grep"
>> not to limit the search space to the current directory.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>>
>> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I
>> once argued in the opposite way, but I think it is Ok to aim for making
>> the default --full-tree in the longer run (cf. $gmane/127885). This is
>> the first step in that direction.
>>
>> I am not sure if there can be a sane way to flip the default without
>> hurting existing scripts and users. Backward compatibility always is
>> a pain.
>
> On a related note, I had planned for a while now to go through the
> commands and check for inconsistencies w.r.t. to subdir default. For
> example, ls-files behaves like grep, whereas status is different. We
> already had discussions about the commit:path notation from a subdir. (I
> don't remember the outcome.) Of course, defaulting status differently
> could be dangerous. Having --full-tree as default for all commands and
> requiring an explicit "." sounds safer for all commands and not overly
> inconvenient. (I remember once wondering where my committed files are,
> looking at git ls-files output from a subdir.)
>
> I think we should make this behavior as uniform across commands as
> possible. Do we have a time frame for 1.7.0 within which one should
> achieve such incompatible changes?
I do not think there is such a consensus for a blanket change like that.
If you are starting a discussion to build one for a particular change (not
necessarily the one you mentioned above) now, you are way too late for
1.7.0. The changes scheduled for 1.7.0 were glitches we have known for
quite some time, and more importantly had a concensus on _how_ they should
be handled long before 1.6.3 (May 6, 2009), and the most importantly, the
steps in the transition plan since then have already been executing.
- The plan for "git push" changes were already announced in 1.6.3, and
the first step of transition was implemented there.
- We already had consensus for changing the default "send-email"
threading behaviour before 1.6.2 and it was scheduled to happen in
1.6.3 but has been deferred until now.
- For a long time, it has been known that it is confusing and unexpected
to users that "git status" is a synonym for "git commit --dry-run".
The plan to make "git status" different from "git commit --dry-run" has
been done in mid August this year.
- For a long time, "git diff" considered -b/-w options are only for
controlling generation of patch text, and these options didn't affect
the exit status (when run with --exit-code) nor suppress the patch
header lines (i.e. "diff --git"). This could be argued as a bug (the
same way as "some commands are relative to cwd by default and others
are relative to the whole tree" can be), but it doesn't mean we can
blame user's scripts for relying on the bug and change the semantics
all of sudden. We had been cooking the change since May 2009 and
announcements were in all issues of "What's cooking" since Aug 2009 for
this change.
Also, please do not confuse 1.7.0 with a license for "I do not like this
and that, screw backward compatibility, and change things as if we were
building git from scratch without any existing users". We need a solid
transition plan to ease the pain for existing scripts and users.
As to ls-files, I haven't seen any good proposal of a smooth transition
plan (like what we laid out for a few semantic changes for "git push" for
1.7.0), if we were to eventually change it, and I personally do not think
there can be a smooth transition for that particular command. It is used
as a very low level building block for people's scripts, and I don't think
of a way to change its fundamental behaviour without causing people a lot
of extra work. I doubt you can easily build a concensus that the benefit
of "consistency" is worth it for such a change.
Side note. What we _could_ do is to make ls-files less (much less)
necessary at the UI level for you to _type_ from the command line.
Enumerate in what situations you used the command, think about the
reason for each of occasions why you used it (e.g. "after a conflicted
merge I wanted to find out which paths are still unresolved and
'ls-files -u' was the most convenient way"), and eliminate the reason
(e.g. "add a new (option to 'merge'|command) that reports the needed
information in much more readable way than 'ls-files -u' does).
The same applies to "$treeish:$path" syntax.
It may be convenient if there were to specify "I want to name the path in
HEAD~47 that corresponds to this file in the directory I am currently in."
But that does not necessarily mean we should change the semantics and
break existing users. One way to satisfy the wish without breaking
existing users would be to start accepting "$treeish:./$relative".
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 19:32 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911250656k31229c42jd79fb94c1a619e59@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> I almost always want only results from "app/soc", so when I run git
> grep I do so from within "app/soc" to make sure I don't get false
> positives from the many external sources we have.
The standard answer given by others has been "you can always say '.' at
the end; having to remember/count number of ../ necessary is much much
more inconvenient".
> PS: I don't mind having to set a config variable to keep the current
> behavior though.
I've thought about it for five seconds before sending my patch, but
discarded it, because I do not see it as a good transition plan.
If it were something like "git-push", that is a purely Porcelain for
causing _effect_ to outside world, the customizable behaviour of the
command depending on which repository it is run is excusable and may even
be beneficial.
But if a command like "grep" that "does one small thing and do it well"
changes its behaviour drastically depending on a config variable or an
environment variable, it won't be a command that you can rely upon any
more in your scripts and hooks. It's the same insanity as GREP_OPTIONS
environment variable.
So this change, if we were to do it, unfortunately has to be "we do it
once and for everybody" a flag day event, I think. That is what I am not
enthused about this patch.
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Mike Jarmy @ 2009-11-25 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eugene Sajine, git
In-Reply-To: <7vaayazb2a.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> I take it to mean that even though v[345] have diverged, the area that the
> particular change you have in mind has to touch haven't changed since they
> forked.
Correct. Sometimes, there might be unrelated changes to a given file
or files, in which case conflict resolution will be done manually.
But generally speaking, bugfixes will tend to go on quite cleanly.
> Instead, you can fork such a topic from the latest common.
>
> o--o--o--o--o--o--o--o v4
> /
> --o--x--x--x--x--x--x--x v3
> \
> Y---Y
> your change(s)
>
> and merging this to v3 and v4 will have the desired effect.
>
> o--o--o--o--o--o--o--o---------M v4
> / /
> --o--x--x--x--x--x--x--x---M v3 /
> \ / /
> Y---Y----------------.-----.
> your change(s)
>
> The merges will incorporate this particular change alone without dragging
> anything else. When you merge it to v4, none of the unrelated 'x' will be
> merged into it.
That sounds a whole lot like what I need.
Right now I'm thinking that the right approach is that once we have
released v3, and started working on v4 heavily, we will probably not
want to check any commits directly into v3. Bugfixes will have their
own branch. If there is a whole new project or whatever being done
on top of v3, it will have its own branch as well.
So once v3 is in beta or whatever and we declare a code freeze, we
could have a rule that all commits must be merge-commits coming from
dedicated branches with descriptive, intelligible names. For each
dedicated branch, some thought will have to be given as to just where
off of v3 to branch it from (not just carelessly off the latest tip).
Meanwhile, new development will continue on v4, with lots of commits
going right into the branch (or into v4 sub-branches with occasional
merge-commits into v4).
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Avery Pennarun @ 2009-11-25 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <7v7htexuxc.fsf@alter.siamese.dyndns.org>
On Wed, Nov 25, 2009 at 2:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> I've read through the thread (I do remember skimming it awhile ago)
>> but can't find patches for the syntax actually under discussion.
>
> I very much prefer gmane threading when following discussion over all the
> other mail archives, but this shows one thing I really dislike about it.
[...]
> Look at http://github.com/gitster/git/commits/jc/merge-theirs/
I also tried simply searching for things like 'git "-xsubtree"' in
google, with no luck. But thanks for the link.
> and found this series in there. It applies to v1.6.0-rc0~245 (no, I won't
> be rebasing this myself---I don't have time for that while preparing for
> the pre-release feature freeze).
I did a test merge and it looks like a ton of conflicts, but they seem
to be pretty understandable ones, at least. I don't mind doing the
rebase and resubmitting the patches, since it's sure less work than
figuring out how to do it from scratch myself. Some questions though:
- What was the reason this never got merged? What changes are needed
to rectify that?
- Considering the earlier discussion, do we want to leave out the
actual -Xtheirs feature and just have -Xours and -Xsubtree?
- If I rebase them and the changes turn out to be minimal, do they
still need a signed-off-by Junio? (He obviously owns part of the
copyright and has previously signed off, but he also won't have signed
off the rebased patches verbatim, so I'm confused.)
Thanks,
Avery
^ permalink raw reply
* Re: [egit] Git repository with multiple eclipse projects ?
From: Yann Simon @ 2009-11-25 19:53 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20091125164734.GF21347@linagora.com>
Le mercredi 25 novembre 2009 à 17:47 +0100, Yann Dirson a écrit :
> It also does not look like it would be possible to use the "share"
> functionnality to setup such a repository from multiple projects (or
> from a project set), right ?
The last time I worked with egit, it was not yet implemented.
Yann
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Sverre Rabbelier @ 2009-11-25 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5rmwgbn.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Nov 25, 2009 at 20:32, Junio C Hamano <gitster@pobox.com> wrote:
> The standard answer given by others has been "you can always say '.' at
> the end; having to remember/count number of ../ necessary is much much
> more inconvenient".
A commandline flag to keep the old behavior then perhaps? "git config
alias.gr 'grep --no-full-tree'" is not that hard to write either.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Junio C Hamano @ 2009-11-25 20:20 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <32541b130911251148v70a5dc77k9936881d0b382ec2@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
>> Look at http://github.com/gitster/git/commits/jc/merge-theirs/
>
> I also tried simply searching for things like 'git "-xsubtree"' in
> google, with no luck. But thanks for the link.
I didn't _find_ the link ;-) I just pushed it out a few minutes ago,
after looking for strings that appear in messages of these commits. The
series was done over a few weeks, and would have been very painful to find
from the gmane archive.
> - What was the reason this never got merged? What changes are needed
> to rectify that?
I do not remember there was any real reason. I do remember some people
didn't like -X<option> syntax but I don't think there was any solid
counterproposal to achieve a similar goal to satisfy the need to pass
arbitrary parameters to the merge strategy backends.
> - Considering the earlier discussion, do we want to leave out the
> actual -Xtheirs feature and just have -Xours and -Xsubtree?
Both -Xtheirs and -Xours have the same degree of badness in the context of
"source code management", but there was a real-world use case that would
have benefitted from -Xours recently.
cf. http://thread.gmane.org/gmane.comp.version-control.git/131902/focus=132920
If -Xours goes in, so should -Xtheirs, I think, because Peter's "web tree"
example could merge in both ways (i.e. he could be pulling from web tree
into his private area and then cleaning things up before pushing the
result back).
> - If I rebase them and the changes turn out to be minimal, do they
> still need a signed-off-by Junio?
"minimal" by definition means that you ased your work on mine and I still
have the copyright to the change as a co-author together with you. We
both need to certify that the change is made under DCO.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 20:23 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911251219t3ad0dacen67d8615ef6eefa02@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Wed, Nov 25, 2009 at 20:32, Junio C Hamano <gitster@pobox.com> wrote:
>> The standard answer given by others has been "you can always say '.' at
>> the end; having to remember/count number of ../ necessary is much much
>> more inconvenient".
>
> A commandline flag to keep the old behavior then perhaps? "git config
> alias.gr 'grep --no-full-tree'" is not that hard to write either.
But then you can alias "gr 'grep --full-tree'" with the same ease and
there is no reason to change the default.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4xggv27.fsf@alter.siamese.dyndns.org>
On Tue, Nov 24, 2009 at 12:56:32AM -0800, Junio C Hamano wrote:
> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I
> once argued in the opposite way, but I think it is Ok to aim for making
> the default --full-tree in the longer run (cf. $gmane/127885). This is
> the first step in that direction.
Ironically, I argued for --full-tree behavior in the same thread, but
have since softened my view. What I have come to realize is that (for
me, anyway) it is very dependent on the organization of the project you
are working on.
For git.git, and most of my small-ish other projects, I want "git grep"
to search the full tree. But recently, I have been working on a
large-ish project imported from svn where the parts of interest to me
are rooted two directories deep (i.e., I am working in
"linux/subproject/", and I don't care at all what's happening in
"windows/otherproject"). I don't want grep hits from the other area to
clutter my output, and I especially don't want to waste time hitting the
disk for those pages, which are an order of magnitude larger than the
working set of files that are actually of interest to me.
On top of that, I think there are two ways within a logical subproject
to use subdirectories. In git.git, I tend to actually chdir into
Documentation/ or t/, because they have their own Makefiles. But for a
project that organizes its code into a bunch of module subdirectories
all driven by a top-level non-recursive Makefile, I tend to stay at the
root and actually do "vi module/foo.c; make".
So what that tells me is:
1. It is not necessarily the _developer_, but a combination of
developer and project that decides which behavior (of --full-tree
and the current behavior) is more useful. Which to me really points
to the utility of a config option.
2. It would be useful to have a "partial-tree" middle ground. In other
words, if I am in "linux/subproject/t", I would find it most
useful if "git grep" searched all of "linux/subproject".
Implementing that would become much more complex, though. Probably
the user would specify a list of rooted subprojects, and we would
prefix-match our path to find which one we were in, and then
do a full-tree grep on that subtree.
And yes, this is somewhat an argument in favor of splitting the
project into submodules. But I'd really rather not do that. They
introduce significant complexity, and the rest of git is so _good_
at ignoring uninteresting parts.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Sverre Rabbelier @ 2009-11-25 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd436uzet.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Nov 25, 2009 at 21:23, Junio C Hamano <gitster@pobox.com> wrote:
> But then you can alias "gr 'grep --full-tree'" with the same ease and
> there is no reason to change the default.
I agree, but then again I'm somewhat biased, as I want the current behavior :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 20:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091125203922.GA18487@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 24, 2009 at 12:56:32AM -0800, Junio C Hamano wrote:
>
>> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I
>> once argued in the opposite way, but I think it is Ok to aim for making
>> the default --full-tree in the longer run (cf. $gmane/127885). This is
>> the first step in that direction.
>
> Ironically, I argued for --full-tree behavior in the same thread, but
> have since softened my view. What I have come to realize is that (for
> me, anyway) it is very dependent on the organization of the project you
> are working on.
I was against --full-tree but wished for it when I dipped my toe into
somebody else's project and my itch lived in a directory a few levels
deep, while the infrastructure the files in the directory uses were spread
across global include directory and platform implementations [*1*].
And I agree that the preferred behaviour depends largely on both the
project and what kind of change you are currently scratching.
So I think the posted patch alone without changing anything else would be
the approach to give the most benefit with the least impact to existing
users, at least for now.
> 2. It would be useful to have a "partial-tree" middle ground. In other
> words, if I am in "linux/subproject/t", I would find it most
> useful if "git grep" searched all of "linux/subproject".
"git grep -e frotz .." will work in your "from linux/subproject/t look for
everywhere in linux/subproject", but if "/t" part were much longer and
variable (iow you need to chdir around inside linux/subproject to scratch
your itch) compared to "linux/subproject" part that is much shorter and
static (to your work), it may make sense to give us a mode to specify
pathspec from the top of the tree.
$ cd linux/subproject
$ cd foo
$ cd bar
$ cd baz
$ git grep --absolute-pathspec -e frotz -- linux/subproject
As "git grep" never takes absolute paths, we _might_ be able to also do
$ git grep -e frotz -- /linux/subproject
to achieve the same.
[Footnote]
*1* It's rockbox, if you need to know.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git
In-Reply-To: <7vr5rmwgbn.fsf@alter.siamese.dyndns.org>
On Wed, Nov 25, 2009 at 11:32:44AM -0800, Junio C Hamano wrote:
> But if a command like "grep" that "does one small thing and do it well"
> changes its behaviour drastically depending on a config variable or an
> environment variable, it won't be a command that you can rely upon any
> more in your scripts and hooks. It's the same insanity as GREP_OPTIONS
> environment variable.
I know this is the attitude we have taken in the past, and I am worried
it is part of what hurts the usability of git. Just consider for a
moment: git grows some feature with a default behavior X. Time passes.
Some people like behavior Y instead. How can we help the people who like
Y?
1. Declare Y better than X, and default to it. This hurts people who
like X. It also hurts scripts built around X.
2. Add a config option to switch the behavior to Y. This hurts people
or scripts unexpectedly using somebody's configuration with Y.
3. Add a --Y command line option. Now the Y people have to remember to
use that option. Every single time they invoke the command.
4. Tell them to alias "git foo-y" to "git foo --Y". IMHO, this is
completely unscalable. They can't just call it "foo", so they have
to remember to invoke "foo-y" each time. And when they forget,
instead of getting an error, they get the X behavior. Furthermore,
as time goes on, they basically develop a vocabulary of git
commands that is totally unlike anybody else's, making their
scripts and git knowledge unportable to other people's setups (sort
of like in (2) above).
So as a Y user, what is the impression of git that I am left with? It
doesn't do what I want unless I remember an option every time, or create
an arcane pseudo-porcelain interface through my set of aliases. Patches
to fix the situation are blocked by compatibility issues. Y users remain
frustrated indefinitely.
I know that (1) and (2) have their problems. But I think by not giving a
little on those compatibility issues, we end up with an equally bad or
worse outcome. In other words, I think in this case that (2) may be the
lesser of many evils.
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Jakub Narebski @ 2009-11-25 20:55 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <200911251536.08993.jnareb@gmail.com>
On Wed, 25 Nov 2009, Jakub Narebski wrote:
> On Wed, 25 Nov 2009 05:01, Stephen Boyd wrote:
> > Jakub Narebski wrote:
> > >
> > > Debugging this is serious PITA. After fix below it appears that this bug
> > > is some intermittent bug, depending on XMLHttpRequest timing. It more
> > > often than not (at least when I tried to debug it using build-in IE8
> > > debugger) works correctly for the folowing files: README, GIT-VERSION-GEN,
> > > revision.c (once even it did fail when first running for given file, and
> > > then running correctly when reloading from debugger; fun it is not).
> > >
> > > It does consistently fail for gitweb/gitweb.perl... but when I tried
> > > to debug it IE8 would hang up when trying to use debugger (with around
> > > 600MB available RAM). Perhaps somebody else would have more luck...
> >
> > Interesting. I don't have time to look into this until early December,
> > but if it's still around then I'll take a look. I wonder if IE6 or IE7
> > works (I don't think everyone is on version 8 yet).
>
> Well, the one time I was able to run debugger (F12, select 'Script', select
> 'gitweb.js') with error occurring
The error was "Unspecified error", char:2 in the mentioned line
> and without IE hanging (for README file) it did show an error for the
> following line:
>
> if (xhr.readyState === 3 && xhr.status !== 200) {
>
> When I checked 'xhr' object, it has "Unknown error" as contents of
> xhr.statusText field and as contents of xhr.status (sic!), which should
> be a number: HTTP status code.
It was 'Unspecified error.' shown in xhr watch. Accessing xhr.status
causes an error.
This might be cause by the fact that xhr (XMLHttpRequest object, or as IE8
shows it in JScript debugger DispHTMLXMLHttpRequest object) is not fully
initialized, or something; gitweb.js calls handleResponse() also from
a timer, to work around the fact that some web browsers onreadystatechange
handler is called only once for each state, and not as soon as new data
is available from server.
Longer term solution would be to use onprogress handler if it is available;
if it is available we don't need trick with calling handleResponse from
timer, as XMLHttpRequest 2.0 proposed specification ensures calling callback
as soon as new data is available.
Short term solution would be to wrap access to xhr.status in try ... catch
block for IE8... although I am a bit reluctant to implement this workaround
bugs in IE8.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqcytjic.fsf@alter.siamese.dyndns.org>
On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:
> So I think the posted patch alone without changing anything else would be
> the approach to give the most benefit with the least impact to existing
> users, at least for now.
Yes, I meant to say in my original message but forgot to: I think
--full-tree is an important first step, no matter what happens next. It
gives people a way to do what they want without typing the right number
of ".."s, and it opens up --no-full-tree if the default changes later.
But I do worry about it being a command-line option. You are asking the
user to remember to type --full-tree every time. I can't count the
number of times I have been in a subdirectory and done "git grep foo",
spent some time analyzing and doing something with the results, only for
my palm to hit my forehead when I realize that I was missing half of the
results I wanted. In other words, I not only have to remember to use the
option, but when I forget, I may get punished very annoyingly by results
which are subtly different from what I want.
So I am in favor of taking it further, but even if we do, the
command-line option is the right thing to be doing _now_.
> "git grep -e frotz .." will work in your "from linux/subproject/t look for
> everywhere in linux/subproject", but if "/t" part were much longer and
> variable (iow you need to chdir around inside linux/subproject to scratch
> your itch) compared to "linux/subproject" part that is much shorter and
> static (to your work), it may make sense to give us a mode to specify
> pathspec from the top of the tree.
>
> $ cd linux/subproject
> $ cd foo
> $ cd bar
> $ cd baz
> $ git grep --absolute-pathspec -e frotz -- linux/subproject
>
> As "git grep" never takes absolute paths, we _might_ be able to also do
>
> $ git grep -e frotz -- /linux/subproject
>
> to achieve the same.
Certainly I think that would be an improvement. But again, it suffers
from the "you must remember to do this" as above. I really want "git
grep" to Do What I Mean.
I have to wonder: is "git grep" really plumbing or porcelain? It is
really just a wrapper for
git ls-files | xargs grep
Do people actually use it in their scripts? Should they be?
-Peff
^ 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