* diff: ignoring changes in certain subdirectories
From: Zoltán Füzesi @ 2009-11-25 13:27 UTC (permalink / raw)
To: git
Hi All, I would like to check changes between branch 'A' and 'B',
ignoring subdirectory 'xyz'.
Is there a simple way?
Thx, Zé
^ permalink raw reply
* Re: diff: ignoring changes in certain subdirectories
From: Johannes Schindelin @ 2009-11-25 13:40 UTC (permalink / raw)
To: Zoltán Füzesi; +Cc: git
In-Reply-To: <9ab80d150911250527j60707333n736c09fcdbdba3a7@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 336 bytes --]
Hi,
On Wed, 25 Nov 2009, Zoltán Füzesi wrote:
> Hi All, I would like to check changes between branch 'A' and 'B',
> ignoring subdirectory 'xyz'. Is there a simple way?
I implement half of this for --no-index some time ago:
http://article.gmane.org/gmane.comp.version-control.git/110846
Feel free to take it to completion,
Dscho
^ permalink raw reply
* jgit problems for file paths with non-ASCII characters
From: Marc Strapetz @ 2009-11-25 13:47 UTC (permalink / raw)
To: git
I have noticed that jgit converts file paths to UTF-8 when querying the
repository. Especially,
org.eclipse.jgit.treewalk.filter.PathFilter#PathFilter performs this
conversion:
private PathFilter(final String s) {
pathStr = s;
pathRaw = Constants.encode(pathStr);
}
Because of this conversion, a TreeWalk fails to identify a file with
German umlauts. When using platform encoding to convert the file path to
bytes:
private PathFilter(final String s) {
pathStr = s;
pathRaw = s.getBytes();
}
the TreeWalk works as expected. Actually, the file path seems to be
stored with platform encoding in the repository.
Is this a bug or a misconfiguration of my repository? I'm using jgit
(commit e16af839e8a0cc01c52d3648d2d28e4cb915f80f) on Windows.
Thanks!
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Re: [PATCH] shortlog: respect commit encoding
From: Uwe Kleine-König @ 2009-11-25 14:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jiri Kosina
In-Reply-To: <7vfx8376hd.fsf@alter.siamese.dyndns.org>
Hello Junio,
On Tue, Nov 24, 2009 at 05:12:14PM -0800, Junio C Hamano wrote:
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
>
> > Before this change the author was taken from the raw commit without
> > reencoding.
>
> I see people often begin with "before this change" and stop the log
> message after making a statement of a fact. I mildly dislike this style,
> especially when the resulting message does not state that it is bad (and
> if necessary why it is bad) nor state in what way the code after the
> change is good.
>
> Don't take the author name information without re-encoding
> from the raw commit object buffer.
>
> is easier to read, at least for me.
Yes, that's better. Thanks.
> > while (*buffer && *buffer != '\n') {
> > const char *eol = strchr(buffer, '\n');
> >
> > - if (eol == NULL)
> > + if (eol == NULL) {
> > eol = buffer + strlen(buffer);
> > - else
> > + } else
> > eol++;
> > if (!prefixcmp(buffer, "author "))
>
> What is this hunk for?
This is just a left-over from debugging. Removed.
> > @@ -157,20 +162,20 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
> > die("Missing author: %s",
> > sha1_to_hex(commit->object.sha1));
> > if (log->user_format) {
> > - struct strbuf buf = STRBUF_INIT;
> > struct pretty_print_context ctx = {0};
> > ctx.abbrev = DEFAULT_ABBREV;
> > ctx.subject = "";
> > ctx.after_subject = "";
> > ctx.date_mode = DATE_NORMAL;
> > + pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &ufbuf, &ctx);
> > + buffer = ufbuf.buf;
> > +
> > + } else if (*buffer)
> > buffer++;
> > +
>
> You probably wanted to add an extra pair of {} around this "else
> if" clause instead, not the earlier one.
I removed the new line (the last changed line you quoted) instead.
Good?
> > diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
> > index 405b971..118204b 100755
> > --- a/t/t4201-shortlog.sh
> > +++ b/t/t4201-shortlog.sh
> > @@ -51,5 +51,29 @@ git log HEAD > log
> > GIT_DIR=non-existing git shortlog -w < log > out
> >
> > test_expect_success 'shortlog from non-git directory' 'test_cmp expect out'
> > +iconvfromutf8toiso885915() {
> > + printf "%s" "$@" | iconv -f UTF-8 -t ISO-8859-15
> > +}
>
> A bad use of "$@" that expands to $# individual words; you meant
> to say "$*".
OK.
> Could we please have the following inside its own test, so that
> any failure while preparing the test data is caught as an error?
I put it in the test itself. Isn't it ugly to have a test saying
something like
* ok 3: prepare shortlog encoding test
? Or is it better to see where a failure occurs?
> > +git reset --hard "$commit"
> > +git config --unset i18n.commitencoding
> > +echo 2 > a1
> > +git commit --quiet -m "set a1 to 2 and some non-ASCII chars: Äßø" --author="Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>" a1
> > +
> > +git config i18n.commitencoding "ISO-8859-15"
> > +echo 3 > a1
> > +git commit --quiet -m "$(iconvfromutf8toiso885915 "set a1 to 3 and some non-ASCII chars: áæï")" --author="$(iconvfromutf8toiso885915 "Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>")" a1
> > +git config --unset i18n.commitencoding
> > +
> > +git shortlog HEAD~2.. > out
> > +
> > +cat > expect << EOF
> > +Jöhännës "Dschö" Schindëlin (2):
> > + set a1 to 2 and some non-ASCII chars: Äßø
> > + set a1 to 3 and some non-ASCII chars: áæï
> > +
> > +EOF
> > +
> > +test_expect_success 'shortlog encoding' 'test_cmp expect out'
>
> t3900-i18n-commit already uses 8859-1 so if it is not too much to
> ask, it would be much nicer to have these test work between UTF-8
> and 8859-1, not -15.
>
> That way, I do not have to worry about breaking tests for people
> who were able to run existing iconv tests because they do not have
> working 8859-15.
OK.
Below is the updated patch.
Best regards
Uwe
------------------>8----------------------
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Subject: [PATCH] shortlog: respect commit encoding
Don't take the author name information without re-encoding from the raw
commit object buffer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
---
builtin-shortlog.c | 20 ++++++++++++--------
t/t4201-shortlog.sh | 23 +++++++++++++++++++++++
2 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 8aa63c7..263adc1 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -139,8 +139,13 @@ static void read_from_stdin(struct shortlog *log)
void shortlog_add_commit(struct shortlog *log, struct commit *commit)
{
const char *author = NULL, *buffer;
+ struct strbuf buf = STRBUF_INIT;
+ struct strbuf ufbuf = STRBUF_INIT;
+ struct pretty_print_context ctx = {0};
- buffer = commit->buffer;
+ pretty_print_commit(CMIT_FMT_RAW, commit, &buf, &ctx);
+
+ buffer = buf.buf;
while (*buffer && *buffer != '\n') {
const char *eol = strchr(buffer, '\n');
@@ -157,20 +162,19 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
die("Missing author: %s",
sha1_to_hex(commit->object.sha1));
if (log->user_format) {
- struct strbuf buf = STRBUF_INIT;
struct pretty_print_context ctx = {0};
ctx.abbrev = DEFAULT_ABBREV;
ctx.subject = "";
ctx.after_subject = "";
ctx.date_mode = DATE_NORMAL;
- pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf, &ctx);
- insert_one_record(log, author, buf.buf);
- strbuf_release(&buf);
- return;
- }
- if (*buffer)
+ pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &ufbuf, &ctx);
+ buffer = ufbuf.buf;
+
+ } else if (*buffer)
buffer++;
insert_one_record(log, author, !*buffer ? "<none>" : buffer);
+ strbuf_release(&ufbuf);
+ strbuf_release(&buf);
}
static void get_from_rev(struct rev_info *rev, struct shortlog *log)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 405b971..03b6950 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -52,4 +52,27 @@ GIT_DIR=non-existing git shortlog -w < log > out
test_expect_success 'shortlog from non-git directory' 'test_cmp expect out'
+iconvfromutf8toiso88591() {
+ printf "%s" "$*" | iconv -f UTF-8 -t ISO-8859-1
+}
+
+cat > expect << EOF
+Jöhännës "Dschö" Schindëlin (2):
+ set a1 to 2 and some non-ASCII chars: Äßø
+ set a1 to 3 and some non-ASCII chars: áæï
+
+EOF
+
+test_expect_success 'shortlog encoding' '
+git reset --hard "$commit" &&
+git config --unset i18n.commitencoding &&
+echo 2 > a1 &&
+git commit --quiet -m "set a1 to 2 and some non-ASCII chars: Äßø" --author="Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>" a1 &&
+git config i18n.commitencoding "ISO-8859-1" &&
+echo 3 > a1 &&
+git commit --quiet -m "$(iconvfromutf8toiso88591 "set a1 to 3 and some non-ASCII chars: áæï")" --author="$(iconvfromutf8toiso88591 "Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>")" a1 &&
+git config --unset i18n.commitencoding &&
+git shortlog HEAD~2.. > out &&
+test_cmp expect out'
+
test_done
--
1.6.5.3
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply related
* Re: git-subtree: directory mismatch
From: Marc Fournier @ 2009-11-25 14:32 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130911241348s21e21fb8n12edf374e6a3c309@mail.gmail.com>
On Tue, Nov 24, 2009 at 04:48:26PM -0500, Avery Pennarun wrote:
> On Tue, Nov 24, 2009 at 2:53 PM, Marc Fournier
> <marc.fournier@camptocamp.com> wrote:
> > I was not able to reproduce this bug in any of the following cases:
> > - if the README file wasn't empty
> > - if modules/cognac is renamed to something else
> > - if modules/cognac doesn't have the same sub-directories than
> > modules/mapserver
> >
> > This bug happens using git 1.5.5.6 as well as 1.6.5. It seems to happen
> > when git-subtree calls "git merge -s subtree".
>
> 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.
I see. What sort of criteria does git-merge use to do this auto-guessing ?
I'm hoping to find a way to workaround this problem. I have a couple of
subtrees I'm completely unable to update. The best I found is:
"git rm -fr ..." followed by "git subtree add ..." again.
> This doesn't usually happen once your project is relatively mature
> (ie. doesn't have blank or "default" template files in it) since then
> the auto-guessing gets more reliable. But there's no good reason to
> do the auto-guessing, so it would be best to do this "properly."
The thing is I use dozens of different "modules" in my project, all merged
into using git-subtree. All these modules have the same structure, and most
of them have quite minimal content and won't really evolve more. In my
case, evolution will mean adding even more modules.
If I understand the thread Nanako Shiraishi pointed us to, a patch
implementing a prefix to "git merge -s subtree" is available somewhere but
hasn't been added in any official release yet ?
Marc
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Jakub Narebski @ 2009-11-25 14:36 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <4B0CAC2E.1060105@gmail.com>
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 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.
Unfortunately I had to take a break... and I was not able to reproduce this
(without hanging web browser: "program not responding") since then...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Sverre Rabbelier @ 2009-11-25 14:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4xggv27.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Nov 24, 2009 at 09:56, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
I regularly rely on this behavior in my usage of git grep. For
example, the Melange project has this layout:
-- app
-- app/soc
-- app/django
-- app/... etc
-- scripts
-- tests
-- thirdparty
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.
Just chiming in for the "want to keep the current behavior" camp :).
PS: I don't mind having to set a config variable to keep the current
behavior though.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Commiting changes onto more than one branch
From: Mike Jarmy @ 2009-11-25 16:31 UTC (permalink / raw)
To: git
Hi,
At my day job, I'm doing the groundwork for recommending that we
switch to a DVCS from a proprietary centralized VCS. I find git's
branching ability very compelling, and I think we would use it
extensively. I work on a very large project (many thousands of files)
that has been around for many years, and has had several different
releases. Right now, each release has its own top level directory,
but I'd like to change that so we use branches instead, out of one
great big git repository. My plan is to set up the repository such
that the initial state at switchover will have a branch for the
current state of each of our releases. Lets say that the branches for
each release are called v1, v2, etc.
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.
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? The very worst thing about our current VCS is that it has no
concept of a 'commit', only individual file histories. Git would fix
that for us, but it would be nirvana if we could group commits for a
given bugfix across branches somehow, while not merging the branches
together.
One last question -- lets make the problem slightly more complicated
by specify that some of the edited files changed between, say, v4 and
v5. I know how to handle a simple merge conflict in git, but is there
anything different about my multi-branched, grouped-together case
here? The answer to this question may be obvious once I understand
how to do the simpler, unconflicting checkin.
Thanks,
Mike Jarmy
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Eugene Sajine @ 2009-11-25 16:38 UTC (permalink / raw)
To: Mike Jarmy; +Cc: git
In-Reply-To: <6b4a562b0911250831q332ac3b5m6ee38f59e7a6f391@mail.gmail.com>
>
> 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?
Thanks,
Eugene
^ permalink raw reply
* 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
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