Re: (unknown)
Patrick Steinhardt writes: > On Tue, Dec 15, 2015 at 09:57:50PM -0800, Junio C Hamano wrote: >> David Greene writes: >> >> > - If new option --keep-redundant is specified, invoke cherry-pick with >> > --keep-redundant-commits. >> >> This came up in the past several weeks, I think; you would need to >> disable patch-equivalence based commit filtering if you really want >> to do a --keep-redundant that is reproducible and/or reliable. > > Here are the links to the previous proposal [1] and following > discussion [2] (see 'ps/rebase-keep-empty') if you are > interested. > > Patrick > > [1]: http://thread.gmane.org/gmane.comp.version-control.git/281515[2]: > http://thread.gmane.org/gmane.comp.version-control.git/281917 Thanks. That makes total sense. I actually would prefer a behavior where cherry-pick would just drop redundant commits rather than stopping and asking the user to reset. The problem is that rebase --preserve-merges seems to force the drop to use cherry-pick and cherry-pick doesn't behave well (from a scripting perspective) in the presence of redundant commits. As it is, it's difficult to rebase as part of a scripted operation due to this issue. Any ideas on how to teach cherry-pick to automatically drop such commits? -David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (unknown)
On Tue, Dec 15, 2015 at 09:57:50PM -0800, Junio C Hamano wrote: > David Greene writes: > > > - If new option --keep-redundant is specified, invoke cherry-pick with > > --keep-redundant-commits. > > This came up in the past several weeks, I think; you would need to > disable patch-equivalence based commit filtering if you really want > to do a --keep-redundant that is reproducible and/or reliable. Here are the links to the previous proposal [1] and following discussion [2] (see 'ps/rebase-keep-empty') if you are interested. Patrick [1]: http://thread.gmane.org/gmane.comp.version-control.git/281515 [2]: http://thread.gmane.org/gmane.comp.version-control.git/281917 signature.asc Description: Digital signature
Re: (unknown)
David Greene writes: > - If new option --keep-redundant is specified, invoke cherry-pick with > --keep-redundant-commits. This came up in the past several weeks, I think; you would need to disable patch-equivalence based commit filtering if you really want to do a --keep-redundant that is reproducible and/or reliable. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: making refs/bisect/ per worktree (was Re: (unknown))
David Turner writes: > This version of the patch series squashes in Junio's comment fix and > the xstrndup fix. > > In addition, it removes refs/worktree, and just makes refs/bisect > per-worktree. If we later discover that other things need to be > per-worktree, we can do refs/worktree, but for now, this is > backwards-compatible so we'll do this. I've already squashed the "make common_list[] static" from Ramsay into 1/3, so no need to resend for that one. Let's wait for a few days to see if people spot any more issues, merge to and cook in 'next' for the remainder of this cycle, and aim to merge this down to 'master' in the first batch after the upcoming release. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which branch(es) contain certain commits? (was Re: (unknown))
On Sat, Aug 22, 2015 at 2:49 PM, Ivan Chernyavsky wrote > >> Note that "branch --list", "tag --list" and "for-each-ref" are being >> revamped to share more internal code. If you want to pursue this, >> you probably would want to build on top of that effort once it is >> done. That way, you may get "tag --grep=FIX123" for free. >> > > This is interesting. So can I have a look on some repo/branch or just wait > until it'll be merged? > This should be what you're looking for: http://thread.gmane.org/gmane.comp.version-control.git/276363 http://thread.gmane.org/gmane.comp.version-control.git/276377 This is the current progress, the rest is in git/next. There is still a series of porting the printing part of branch.c to be done. -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which branch(es) contain certain commits? (was Re: (unknown))
22.08.2015, 12:19, "Ivan Chernyavsky" :
> One thing I'm worried about is that git-branch already has option --all. So
> we'll get a semantics conflict with setup_revisions() ("all branches" vs "all
> refs"). This will have to be treated carefully, e.g. retrace and fix effects
> of --all after setup_revisions() to include just branches but not other refs.
> Will such mangling be ok? Or could I prepare the call of setup_revisions() in
> a way that only branches will be included by --all? Anyway the semantics of
> --all will be different for git-branch and git-rev-list, but I believe more
> important is to keep it unchanged for git-branch.
>
Please disregard this part. I should just gobble --all with the existing
parse_options() and do not provide it to setup_revisions() altogether.
--
Ivan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which branch(es) contain certain commits? (was Re: (unknown))
22.08.2015, 01:39, "Junio C Hamano" :
> Ivan Chernyavsky writes:
>
>> Another problem is that builtin/branch.c currently does not use
>> setup_revisions(), so I'll have to hook it there as well.
>
> Heh, you say "problem" above, but I do not think it is a "problem"
> per-se. If you want to teach branch some preprocessing based on the
> revision traversal API, you naturally need to call setup_revisions().
I meant "my problem" mostly ;) Yes I see git-branch currently has it's own way
of doing things, I assume it avoids more heavy machinery from git-rev-list and
friends.
> The outlined steps above all feel sensible; one thing you did not
> mention is that you may probably have to clear object flags after
> you are done with the initial "--grep" revision traversal, as some
> features of branch may want to use the object flags (e.g. --merged
> would use in_merge_bases()). Other than that, all of it sounds
> easily implementable.
I still need to understand a lot how it all works. Any hint on where to look is
appreciated. (I started from looking on builtin/shortlog.c just because it's
one of the shortest ones using setup_revisions().)
One thing I'm worried about is that git-branch already has option --all. So
we'll get a semantics conflict with setup_revisions() ("all branches" vs "all
refs"). This will have to be treated carefully, e.g. retrace and fix effects of
--all after setup_revisions() to include just branches but not other refs. Will
such mangling be ok? Or could I prepare the call of setup_revisions() in a way
that only branches will be included by --all? Anyway the semantics of --all
will be different for git-branch and git-rev-list, but I believe more important
is to keep it unchanged for git-branch.
> Note that "branch --list", "tag --list" and "for-each-ref" are being
> revamped to share more internal code. If you want to pursue this,
> you probably would want to build on top of that effort once it is
> done. That way, you may get "tag --grep=FIX123" for free.
>
This is interesting. So can I have a look on some repo/branch or just wait
until it'll be merged?
>> That said, do you think the goal is worth such changes?
>
> That is a dangerous question. As Duy already said,
>
>> Probably because nobody is interested and steps up to do it. The lack
>> of response to you mail is a sign.
>
> apparently not many people thought it is worth; otherwise we would
> already have such a feature.
>
> If you are asking me personally, I'm sorry but I have to say no.
>
> The reason why I personally do not think your "branch --grep=FIX123"
> would be very useful to me is because I would imagine that I would
> be interested in learning the exact commit that mentions FIX123 as
> well as which branches contain it, if I had a need for such a
> feature.
>
> That is, it would inherently be two step process for me anyway, i.e.
>
> (1) I'd run "log -p --grep" to find which commits are about FIX123
> and check that what they did indeed make sense; and
>
> (2) I'd then run "branch --contains" to learn which ones are
> already up to date with respect to the fix.
>
> Your "branch --grep=FIX123" that only tells me the names of branches
> would have no use in that workflow, as it would not even give me an
> indication that the request --grep=FIX123 found the right commit in
> the first place.
Yes, I see your point. But let me also explain my use case so it'll be probably
more clear. Sorry if it's too long.
I work for HP as SCM and build manager for a product >15 years old. One of this
product's greatest strenghts always was support for many old releases and
customizations for particular users. So right now we are providing support for
10 subsequent releases (oldest one released back in 2006), and each release has
5 to 10 "customer" branches with their specific enhancements and fixes.
(Though, as you would expect, all the fixes are generally merged to mainline,
some customers are reluctant to apply fixes they don't need, so even here we
must be flexible when preparing a patch.) So basically now I'm managing around
60 public branches in the repository.
SCM was ClearCase at the beginning, then StarTeam (whoa, complete disaster). At
this point I joined the team and performed migration to Git last year (took a
whole year). So now our history is a mixture of ancient baselines from
ClearCase and artificial branches imported from StarTeam (thanks to my
colleague who wrote a Git helper for StarTeam,
https://github.com/AndreyPavlenko/git-st). So many changes which are 100%
identical are represented by different commits, only identifiable with
--cherry-pick option to git-log and friends. Even if I spent a great amount of
time manually cutting and glueing history in Git to have the shortest logs.
And obviously, our workflow is based on cherry-picks, because very very often
fixes and enhancements have to be merged *back* to many old customer branche
Re: Which branch(es) contain certain commits? (was Re: (unknown))
Ivan Chernyavsky writes: > But now I had a look on the source and I can see that builtin/branch.c > builds the list of references and prints them in a single place > (print_ref_list()) so I will have to split that function into two in > order to reuse existing functionality. > > Another problem is that builtin/branch.c currently does not use > setup_revisions(), so I'll have to hook it there as well. > > Then, I assume, I'll need to use the initial ref_list (filled the same > as for the current "list" case) to configure the rev_info structure > after setup_revisions(), and start revision traversal. > > I'm not sure I've got it all right from the source in those few days, > so I apologize in advance if it's stupid in some part or as a whole. Heh, you say "problem" above, but I do not think it is a "problem" per-se. If you want to teach branch some preprocessing based on the revision traversal API, you naturally need to call setup_revisions(). The outlined steps above all feel sensible; one thing you did not mention is that you may probably have to clear object flags after you are done with the initial "--grep" revision traversal, as some features of branch may want to use the object flags (e.g. --merged would use in_merge_bases()). Other than that, all of it sounds easily implementable. Note that "branch --list", "tag --list" and "for-each-ref" are being revamped to share more internal code. If you want to pursue this, you probably would want to build on top of that effort once it is done. That way, you may get "tag --grep=FIX123" for free. > That said, do you think the goal is worth such changes? That is a dangerous question. As Duy already said, > Probably because nobody is interested and steps up to do it. The lack > of response to you mail is a sign. apparently not many people thought it is worth; otherwise we would already have such a feature. If you are asking me personally, I'm sorry but I have to say no. The reason why I personally do not think your "branch --grep=FIX123" would be very useful to me is because I would imagine that I would be interested in learning the exact commit that mentions FIX123 as well as which branches contain it, if I had a need for such a feature. That is, it would inherently be two step process for me anyway, i.e. (1) I'd run "log -p --grep" to find which commits are about FIX123 and check that what they did indeed make sense; and (2) I'd then run "branch --contains" to learn which ones are already up to date with respect to the fix. Your "branch --grep=FIX123" that only tells me the names of branches would have no use in that workflow, as it would not even give me an indication that the request --grep=FIX123 found the right commit in the first place. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Which branch(es) contain certain commits? (was Re: (unknown))
17.08.2015, 20:49, "Junio C Hamano" : > Duy Nguyen writes: > >> On Wed, Aug 5, 2015 at 7:47 PM, Ivan Chernyavsky >> wrote: > > That is a dangeous thought. I'd understand if it were internally > two step process, i.e. (1) the first pass finds commits that hits > the --grep criteria and then (2) the second pass does "--contains" > for all the hits found in the first pass using existing code, but > still, this operation is bound to dig all the way through the root > of the history when asked to find something that does not exist. My intention was to use existing git-branch filters such as -a or -r and pattern to limit the scope, then apply --grep machinery. But now I had a look on the source and I can see that builtin/branch.c builds the list of references and prints them in a single place (print_ref_list()) so I will have to split that function into two in order to reuse existing functionality. Another problem is that builtin/branch.c currently does not use setup_revisions(), so I'll have to hook it there as well. Then, I assume, I'll need to use the initial ref_list (filled the same as for the current "list" case) to configure the rev_info structure after setup_revisions(), and start revision traversal. I'm not sure I've got it all right from the source in those few days, so I apologize in advance if it's stupid in some part or as a whole. That said, do you think the goal is worth such changes? Seems like git-branch currently has it's own way of doing things and I'm trying to teach it to use git-rev-list's. Maybe it is more reasonable to add an option to "git log --all --source --grep=..." to print *all* branch tips which are reachable from the found commits, not only the first one encountered? E.g. --decorate-all or --source-all? > You should at least feed all --contains to a single invocation of > "git branch". They are designed to be OR'ed together. Yep thanks I overlooked that. In my repository, this takes 40 seconds instead of 2 minutes 30 seconds for my construct. -- Ivan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which branch(es) contain certain commits? (was Re: (unknown))
15.08.2015, 12:19, "Duy Nguyen" : > > Probably because nobody is interested and steps up to do it. The lack > of response to you mail is a sign. Maybe you can try make a patch? I > imagine it would not be so different from current --contains code, but > this time we need to look into commits, not just commit id. > Yeah thanks much, I'll try. Actually that was my original intention, I just wanted to have some "reasonability check" for my idea. -- Ivan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which branch(es) contain certain commits? (was Re: (unknown))
Sorry for empty subject in the original mail, somehow I've deleted it and didn't even notice. 05.08.2015, 20:05, "Junio C Hamano" : > Junio C Hamano writes: > >> I think people do things like: >> >> git log --all --decorate --grep=... > > s/decorate/source/; sorry for the noise. Thanks Junio! I was actually considering using --source, but for me the problem is it always returns *just one* branch for every matching commit. So the caller must then use his own knowledge to deduce all branches where this branch merged. Considering following history: * b46f30e refs/heads/zzz eee | * dc0280f refs/heads/yyy ddd |/ | * 31739da refs/heads/xxx ccc |/ * a42bd23 refs/heads/master bbb * 01a8291 refs/heads/master aaa Command "git log --all --source --grep=bbb --oneline" will return: a42bd23 refs/heads/master bbb While I'm expecting something like "git branch --contains=a42bd23" output in terms of *all* topics being listed: master xxx yyy * zzz The most common use case is when support people need to quickly get at least rough idea which branches have specific ticket/CR mentioned. -- Ivan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which branch(es) contain certain commits? (was Re: (unknown))
Junio C Hamano writes: > I think people do things like: > > git log --all --decorate --grep=... s/decorate/source/; sorry for the noise. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Which branch(es) contain certain commits? (was Re: (unknown))
Ivan Chernyavsky writes: > For some time I'm wondering why there's no "--grep" option to the "git > branch" command, which would request to print only branches having > specified string/regexp in their history. > > So for example: > > $ git branch -r --grep=BUG12345 > > should be roughly equivalent to following expression I'm using now for the > same task: > > $ for r in `git rev-list --grep=BUG12345 --remotes=origin`; do git > branch -r --list --contains=$r 'origin/*'; done | sort -u > > Am I missing something, is there some smarter/simpler way to do this? I think people do things like: git log --all --decorate --grep=... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unknown option for merge-recursive: -Xdiff-algorithm=minimal
On Tue, Sep 24, 2013 at 10:00:30AM +0100, Luke Noel-Storr wrote:
> I'm trying to use the diff-algorithm option for recursive merge, but
> get the above error. I've tried various different ways of specifying
> the option, but none work.
>
> To try and find what the correct syntax is I tried peeping into the
> source code, and it looks like it may actually be an error in the
> code.
>
> This is from merge-recursive.c line 2072:
>
> else if (!strcmp(s, "diff-algorithm=")) {
> long value = parse_algorithm_value(s+15);
> if (value < 0)
> return -1;
> /* clear out previous settings */
> DIFF_XDL_CLR(o, NEED_MINIMAL);
> o->xdl_opts &= ~XDF_DIFF_ALGORITHM_MASK;
> o->xdl_opts |= value;
> }
>
> I believe !strcmp(s, "diff-algorithm=") should actually be !prefixcmp(s,
> "diff-algorithm=")
>
> Could someone confirm this is a bug, and is there any other way I can specify
> the diff algorithm?
I think you're right - this should be prefixcmp.
The simplest thing to do would be to patch it locally and run your own
build - Git's Makefile installs in your home directory by default, so
providing $HOME/bin is on your path, "make install" will just give you
something that works.
Of course, you should then submit the patch here ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: (unknown)
e...@thyrsus.com (Eric S. Raymond) writes:
> From: "Eric S. Raymond"
> Date: Fri, 28 Dec 2012 11:40:59 -0500
> Subject: [PATCH] Add checks to Python scripts for version dependencies.
>
> ---
> contrib/ciabot/ciabot.py | 8 +++-
> ...
> diff --git a/contrib/fast-import/import-zips.py
> b/contrib/fast-import/import-zips.py
> index 82f5ed3..b989941 100755
> --- a/contrib/fast-import/import-zips.py
> +++ b/contrib/fast-import/import-zips.py
> @@ -9,10 +9,15 @@
> ## git log --stat import-zips
>
> from os import popen, path
> -from sys import argv, exit
> +from sys import argv, exit, hexversion
> from time import mktime
> from zipfile import ZipFile
>
> +if hexversion < 0x0106:
I am assuming that you are carefully limiting what you import from
"sys" by adding only hexversion to the import above, but then can we
refer to sys.stderr below?
> + # The limiter is the zipfile module
> +sys.stderr.write("import-zips.py: requires Python 1.6.0 or later.\n")
> +sys.exit(1)
> +
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
