* Re: [PATCH] Documentation: More examples for git bisect
From: Christian Couder @ 2009-03-06 20:08 UTC (permalink / raw)
To: John Tapsell; +Cc: git
In-Reply-To: <1236332255-15712-1-git-send-email-johnflux@gmail.com>
Le vendredi 6 mars 2009, John Tapsell a écrit :
> Including passing parameters to the programs, and running more
> complicated checks without requiring a seperate shell script.
>
> Signed-off-by: John Tapsell <johnflux@gmail.com>
> ---
> Documentation/git-bisect.txt | 27 ++++++++++++++++++++++++++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 147ea38..7b8cfdd 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -212,7 +212,7 @@ If you have a script that can tell if the current
> source code is good or bad, you can automatically bisect using:
>
> ------------
> -$ git bisect run my_script
> +$ git bisect run my_script arguments
> ------------
>
> Note that the "run" script (`my_script` in the above example) should
> @@ -251,6 +251,22 @@ EXAMPLES
> $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
> $ git bisect run make # "make" builds the app
> ------------
> ++
> +This looks for the first revision that fails to build between HEAD and
> +the tag 'v1.2'.
There are a few trailing spaces in the above line but otherwise the patch
looks good to me.
Acked-by: Christian Couder <chriscool@tuxfamily.org>
By the way, it would be nice if you could put me in CC.
Thanks,
Christian.
^ permalink raw reply
* Re: fetch and pull
From: Junio C Hamano @ 2009-03-06 19:27 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A115E0D@EXCHANGE.trad.tradestation.com>
"John Dlugosz" <JDlugosz@TradeStation.com> writes:
> I've gotten the hang of git well enough to pretty much bang on it until
> I achieve what I wanted to happen, though maybe trying a few things and
> recovering from mistakes or taking the long way around.
>
> Now I'm putting together a cookbook for our team, to allow use of topic
> branches rather than treating it simply as a faster SourceSafe.
>
> I want to advocate running
>
> git fetch
>
> as being a safe thing to do at any time, just to refresh your view of
> the origin and not mess up any of your local labels. That is, you can
> see the difference between the local dev and the origin/dev.
>
> So, after inspecting the changes, how do you fast-forward your local dev
> to sync up with origin/dev?
$ git push . origin/dev dev
^ permalink raw reply
* Using Git with windows
From: John Dlugosz @ 2009-03-06 19:10 UTC (permalink / raw)
To: git; +Cc: tariq.hassanen
I can think of two differences: Line endings have been mentioned already.
But, and I was wondering this already anyway, does the Windows git know that the file system is case insensitive but case preserving? That is, does it just ignore the issue, is there logic to cope with that better? If so, that would be missing if you ran it in the Linux VM. (Unless it checks the file system capabilities rather than the OS it is running under)
--John
(please excuse the footer; it is not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* fetch and pull
From: John Dlugosz @ 2009-03-06 19:04 UTC (permalink / raw)
To: git
I've gotten the hang of git well enough to pretty much bang on it until
I achieve what I wanted to happen, though maybe trying a few things and
recovering from mistakes or taking the long way around.
Now I'm putting together a cookbook for our team, to allow use of topic
branches rather than treating it simply as a faster SourceSafe.
I want to advocate running
git fetch
as being a safe thing to do at any time, just to refresh your view of
the origin and not mess up any of your local labels. That is, you can
see the difference between the local dev and the origin/dev.
So, after inspecting the changes, how do you fast-forward your local dev
to sync up with origin/dev?
I'm worried that
git pull origin dev
will try to merge into the current head. The documentation indicates
"The remote ref that matches <src> is fetched, and if <dst> is not empty
string, the local ref that matches it is fast forwarded using <src>."
which is what I want, but it does NOT say that the normal behavior of
merging origin/dev into the =current= HEAD, if it happens to not be the
local dev.
So, does it indeed suppress that behavior if you give it an explicit
destination? Or will I have to checkout dev first before doing the
pull, to prevent strange things from happening? Hmm, or perhaps I
should be using merge, not pull? After all, pull is really just a
wrapper around fetch and then merge, right? So is it OK to call merge
when I really want to fast-forward, and is there an option to give an
error if it isn't ff?
--John
(sorry about the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-03-06 17:57 UTC (permalink / raw)
To: git
In-Reply-To: <eaa105840903060858g5b8f31bpb9a59d563835a9d5@mail.gmail.com>
On Fri, Mar 06, 2009 at 11:58:36AM -0500, Peter Harris wrote:
> On Fri, Mar 6, 2009 at 11:10 AM, Josef Wolf wrote:
> > On Thu, Mar 05, 2009 at 02:48:14PM -0500, Peter Harris wrote:
> >>
> >> True, but in my experience it happens considerably less often with
> >> git. I find and fix most of my typos when reviewing my change-set
> >> before doing a "git push" or "git svn dcommit".
> >
> > So you are rewriting yourself but not accept rewrites by svn ;-)
>
> No, I am not rewriting myself *after I publish*. I see the smiley, but
> I think you missed the point.
>
> "git push" or "svn ci" is the end of the rewrites.
I see. Thanks for the clarification!
> >> Indeed. Or even not-so-random names, such as cloneX/topic-name if you
> >> prefer.
> >
> > That would have the risk of multiple clones pushing to the same branch.
>
> Only if cloneX pushes to cloneY/topic-name. Does each clone not have a
> unique name?
I'd rather not rely on the clones having unique names.
> > Does that look sane?
>
> No. But it doesn't look any more insane than any other workflow
> involving Subversion that I can think of. :-)
OK, I parse that as "there's not much room for improvement" :-)
Thanks for your great help! I have learned a lot in this thread!
^ permalink raw reply
* Re: [PATCH 4/5] Keep '*' in pattern refspecs
From: Daniel Barkalow @ 2009-03-06 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsklrt66z.fsf@gitster.siamese.dyndns.org>
On Fri, 6 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > In order to do anything more capable with refspecs, the first step is
> > to keep the entire input. Additionally, validate patterns by checking
> > for the ref matching the rules for a pattern as given by
> > check_ref_format(). This requires a slight change to make it require
> > the '*' to be at the beginning of a path component.
>
> I had a brief "Huh?" moment wondering about this "slight change", but at
> this stage it does not change the rule at all ("/*" still must happen at
> the end of the string), so there actually is no change.
Ah, yes. A slight change to the code in refs.c to enforce the rule that
was enforced previously in remote.c.
> > diff --git a/remote.c b/remote.c
> > index 93fd03d..d0ce4c6 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -722,10 +716,10 @@ int remote_has_url(struct remote *remote, const char *url)
> > static int name_fits_pattern(const char *key, const char *name,
> > const char *value, char **result)
> > {
> > - size_t klen = strlen(key);
> > - int ret = !strncmp(key, name, klen);
> > + size_t klen = strchr(key, '*') - key;
> > + int ret = !strncmp(name, key, klen);
>
> Any particular reason why the first parameters to strncmp() were swapped?
An artifact of how I cleaned up the series that I didn't notice; I
originally wrote it from scratch with strncmp, with an arbitrary argument
order. Then I split out 2/5 using prefixcmp, and 3/5 keeping prefixcmp's
order, and didn't notice I didn't need the line of diff. So not really.
> > if (ret && value) {
> > - size_t vlen = strlen(value);
> > + size_t vlen = strchr(value, '*') - value;
>
> We would want protection from programming error here, to catch keys and
> values without any asterisk. This comment also applies to [5/5].
Good idea.
> > *result = xmalloc(vlen +
> > strlen(name) -
> > klen + 1);
>
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/5] Use the matching function to generate the match results
From: Daniel Barkalow @ 2009-03-06 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6vjt679.fsf@gitster.siamese.dyndns.org>
On Fri, 6 Mar 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This puts all of the interpretation of the pattern representation in a
> > single function for easy manipulation.
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
>
> I think this makes sense, but the helper function is not about "does this
> name match the pattern?" boolean anymore, and may want to be renamed to
> e.g. map_name_with_pattern().
I'll just make it "match_name_with_pattern" from the beginning, which
describes what it does whether or not the later arguments are NULL.
> > -static int name_fits_pattern(const char *key, const char *name)
> > +static int name_fits_pattern(const char *key, const char *name,
> > + const char *value, char **result)
> > {
> > - int ret = !prefixcmp(key, name);
> > + size_t klen = strlen(key);
> > + int ret = !strncmp(key, name, klen);
> > + if (ret && value) {
> > + size_t vlen = strlen(value);
> > + *result = xmalloc(vlen +
> > + strlen(name) -
> > + klen + 1);
> > + strcpy(*result, value);
> > + strcpy(*result + vlen, name + klen);
> > + }
>
> > @@ -1080,11 +1085,9 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
> >
> > } else {
> > const char *dst_side = pat->dst ? pat->dst : pat->src;
> > - dst_name = xmalloc(strlen(dst_side) +
> > - strlen(src->name) -
> > - strlen(pat->src) + 2);
> > - strcpy(dst_name, dst_side);
> > - strcat(dst_name, src->name + strlen(pat->src));
> > + if (!name_fits_pattern(pat->src, src->name,
> > + dst_side, &dst_name))
> > + die("Didn't think it matches any more");
> > }
>
> Hmm, we have been overallocating and nobody noticed so far?
Probably. I suspect that we're making sure to have room for the '\0's at
the end of both the base and the part that matches the star. Looks like
it's still how Alex Riesen wrote it, sort of arbitrarily one byte longer
than the similar allocation.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured
From: Junio C Hamano @ 2009-03-06 17:17 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johannes Schindelin, Finn Arne Gangstad, Sverre Rabbelier,
markus.heidelberg, git, John Tapsell, Andreas Ericsson
In-Reply-To: <m3r61aisdo.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> Speaking of which, Steffen (who cannot reply right now, since he is AFK
>> for a while) had a patch to install "remote.<branch>.push = HEAD" with
>> clone and remote. Would that be better?
>
> Errr... I thought that "remote.<remotename>.push = HEAD" works?
>
> But note that "remote.<name>.push = HEAD" (push current branch only)
> and "remote.<name>.push = :" (push matching branches, i.e. curent
> behavior) works only if you have remote configured... "git push <URL>"
> won't be affected, and people (probably) would want to either have
> 'nothing' as default, or/and be able to configure it to nothing,
> current, or matching (at least).
When you and Dscho contradict with each other, I seem to end up agreeing
with Dscho most of the time, but for this particular one, I completely
agree with you.
I personally think Finn's suggested list is overengineered, and we should
start with only three: "nothing", "current" (aka HEAD), and "matching".
It is Ok to have a separate discussion to figure out what other default
behaviours are desireable, but I think that should come after the dust
settled from the transition, and more importantly, I think the other kinds
of fine-tuned behaviour needs to be per-remote, and is not something the
repository (or user) wide default push.default can cover.
In addition to your counterargument, clone to set up remote.*.push is
introducing an inconsistency between existing and new repositories until
the default is changed for everybody, and the recent trend is to avoid
that kind of inconsistency. Steffen's patch _could_ use push.default to
infer what kind of remote.*.push to set up when adding a remote (or when
cloning, if you take push.default from $HOME/.gitconfig), but at that
point it becomes a redundant information.
^ permalink raw reply
* msysgit corrupting commit messages?
From: Sam Hocevar @ 2009-03-06 17:11 UTC (permalink / raw)
To: git
In-Reply-To: <CYOA8Q1cpfGtE1Pp6_ETXfSJevKv9ADmYIuq6_whU0qskk289fiiUw@cipher.nrlssc.navy.mil>
On Fri, Mar 06, 2009, Brandon Casey wrote:
> I get the impression that you do not intend for the comments above to be
> part of the commit message. If that is true, then they should be placed
> further down after the '---' and before the diff-stat, or in some other
> way partitioned from the commit message (maybe using --->8--- notation).
> Otherwise they will _become_ part of the commit message if Junio applies
> this patch as-is.
Okay. I'm definitely having a problem with git on MSYS. Is anyone
else seeing it butcher commits it exports? They appear fine in git log
or git log -p, but not in git format-patch. I've never had the problem
on a Linux system.
--
Sam.
^ permalink raw reply
* Re: how to have --no-ff be the default for all branch
From: Jay Soffian @ 2009-03-06 17:01 UTC (permalink / raw)
To: jean-luc malet; +Cc: git
In-Reply-To: <1de9d39c0903060245u45373b8cq10d52f353c2214e2@mail.gmail.com>
2009/3/6 jean-luc malet <jeanluc.malet@gmail.com>:
> I would like that it is the default for all branch and that I use --ff
> when I want to do fast forward merge
> I know that I can set it up for one branch
> git config add branch.master.mergeoption --no-ff
> but I want it to be the default no just for one branch but for all branch
> git config add branch.*.mergeoption --no-ff
> don't work....
>
> how can I do that?
Not currently possible. The best you can do currently is to make an alias.
It would be a fairly trivial patch though to support merge.options. :-)
j.
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Peter Harris @ 2009-03-06 16:58 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090306161026.GA14554@raven.wolf.lan>
On Fri, Mar 6, 2009 at 11:10 AM, Josef Wolf wrote:
> On Thu, Mar 05, 2009 at 02:48:14PM -0500, Peter Harris wrote:
>>
>> True, but in my experience it happens considerably less often with
>> git. I find and fix most of my typos when reviewing my change-set
>> before doing a "git push" or "git svn dcommit".
>
> So you are rewriting yourself but not accept rewrites by svn ;-)
No, I am not rewriting myself *after I publish*. I see the smiley, but
I think you missed the point.
"git push" or "svn ci" is the end of the rewrites.
The critical difference is that I can easily manage an entire
unpublished patch series in git. I cannot in svn (without 3rd party
tools such as quilt or git-svn, anyway). So in svn if I notice a typo
near the beginning of a patch series as I am publishing the last of
the series, I'm screwed.
>> Indeed. Or even not-so-random names, such as cloneX/topic-name if you
>> prefer.
>
> That would have the risk of multiple clones pushing to the same branch.
Only if cloneX pushes to cloneY/topic-name. Does each clone not have a
unique name?
> Does that look sane?
No. But it doesn't look any more insane than any other workflow
involving Subversion that I can think of. :-)
Peter Harris
^ permalink raw reply
* Re: [PATCH] git-p4: remove unnecessary semicolons at end of lines
From: Brandon Casey @ 2009-03-06 16:55 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git
In-Reply-To: <20090306155322.GC12880@zoy.org>
Sam Hocevar wrote:
> This is a purely cosmetic patch that makes the git-p4 code look more
> pythonish by getting rid of end-of-line semicolons.
I get the impression that you do not intend for the comments above to be
part of the commit message. If that is true, then they should be placed
further down after the '---' and before the diff-stat, or in some other
way partitioned from the commit message (maybe using --->8--- notation).
Otherwise they will _become_ part of the commit message if Junio applies
this patch as-is.
-brandon
> git-p4: remove unnecessary semicolons at end of lines.
>
> Signed-off-by: Sam Hocevar <sam@zoy.org>
> ---
Comments not intended to be part of the commit message go here, where they
will be ignored by git-apply.
> contrib/fast-import/git-p4 | 46 ++++++++++++++++++++++----------------------
> 1 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 3832f60..7ea5ac6 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -12,7 +12,7 @@ import optparse, sys, os, marshal, popen2, subprocess, shelve
<snip>
^ permalink raw reply
* Re: [PATCH 2/3] bash completion: refactor --strategy completion
From: Shawn O. Pearce @ 2009-03-06 16:32 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Markus Heidelberg, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <1236357044-55479-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> wrote:
> The code to complete --strategy was duplicated between _git_rebase and
> _git_merge, and is about to gain a third caller (_git_pull). This patch
> factors it into its own function.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> How about like this intead? This way 3/3 doesn't need to be adjusted. The
> interdiff is:
Yup, that works too!
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 38 ++++++++++++++++---------------
> 1 files changed, 20 insertions(+), 18 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/3] bash completion: refactor --strategy completion
From: Jay Soffian @ 2009-03-06 16:30 UTC (permalink / raw)
To: git
Cc: Jay Soffian, Markus Heidelberg, Sverre Rabbelier, Junio C Hamano,
Shawn O . Pearce
In-Reply-To: <20090306161657.GJ16213@spearce.org>
The code to complete --strategy was duplicated between _git_rebase and
_git_merge, and is about to gain a third caller (_git_pull). This patch
factors it into its own function.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
How about like this intead? This way 3/3 doesn't need to be adjusted. The
interdiff is:
---snip---
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9e16576..056e43e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -449,15 +449,16 @@ __git_complete_strategy ()
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
__gitcomp "$(__git_merge_strategies)"
- return 1
+ return 0
esac
+ local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
__gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
- return 1
+ return 0
;;
esac
- return 0
+ return 1
}
__git_all_commands ()
---snap---
contrib/completion/git-completion.bash | 38 ++++++++++++++++---------------
1 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e8c4be2..056e43e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -444,6 +444,23 @@ __git_complete_remote_or_refspec ()
esac
}
+__git_complete_strategy ()
+{
+ case "${COMP_WORDS[COMP_CWORD-1]}" in
+ -s|--strategy)
+ __gitcomp "$(__git_merge_strategies)"
+ return 0
+ esac
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --strategy=*)
+ __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ return 0
+ ;;
+ esac
+ return 1
+}
+
__git_all_commands ()
{
if [ -n "${__git_all_commandlist-}" ]; then
@@ -1095,17 +1112,10 @@ _git_log ()
_git_merge ()
{
+ __git_complete_strategy && return
+
local cur="${COMP_WORDS[COMP_CWORD]}"
- case "${COMP_WORDS[COMP_CWORD-1]}" in
- -s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
- return
- esac
case "$cur" in
- --strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
- return
- ;;
--*)
__gitcomp "
--no-commit --no-stat --log --no-log --squash --strategy
@@ -1174,16 +1184,8 @@ _git_rebase ()
__gitcomp "--continue --skip --abort"
return
fi
- case "${COMP_WORDS[COMP_CWORD-1]}" in
- -s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
- return
- esac
+ __git_complete_strategy && return
case "$cur" in
- --strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
- return
- ;;
--*)
__gitcomp "--onto --merge --strategy --interactive"
return
--
1.6.2.rc2.332.g5d21b
^ permalink raw reply related
* Re: setting up tracking on push
From: Miles Bader @ 2009-03-06 16:29 UTC (permalink / raw)
To: git
In-Reply-To: <76718490903060743m425c2d55n6e8737c893c936e8@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> I don't think we need a new command, but it would probably fit into
> git remote
>
> $ git remote track <remote> [<branch>]
That seems a bit backwards -- it's more of a branch operation than a
remote operation...
-Miles
--
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.
^ permalink raw reply
* Re: [PATCH JGIT] Fix parsing peeled line in packed-ref
From: Shawn O. Pearce @ 2009-03-06 16:19 UTC (permalink / raw)
To: Daniel Cheng (aka SDiZ); +Cc: git, Daniel Cheng (aka SDiZ)
In-Reply-To: <1236355550-5764-1-git-send-email-j16sdiz+freenet@gmail.com>
"Daniel Cheng (aka SDiZ)" <j16sdiz+freenet@gmail.com> wrote:
> From: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@sdiz.net>
>
> When doing a WalkTransport with packed-ref, peeled
> line are not handled correctly. This patch fix the issue.
>
> Signed-off-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
Thanks. Fix pushed.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/3] bash completion: refactor --strategy completion
From: Shawn O. Pearce @ 2009-03-06 16:16 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Markus Heidelberg, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <76718490903060812q2e7b2eefg5f25c9845f678959@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> wrote:
> On Fri, Mar 6, 2009 at 11:04 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Jay Soffian <jaysoffian@gmail.com> wrote:
> >> The code to complete --strategy was duplicated between _git_rebase and
> >> _git_merge, and is about to gain a third caller (_git_pull). This patch
> >> factors it into its own function.
> >>
> >> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> >
> > Looks OK to me, but I had to squash this in to get it to work.
> > Without this the patch breaks git merge completion entirely:
>
> Weird, I had it completely backwards but it seemed to work. Probably
> because I was sourcing the new completion into my running shell; I'll
> make sure to startup a new shell next time.
>
> With the squash (assuming Junio doesn't mind), is it acked-by you or
> should I resend?
Sorry, yes, with the squash it is Ack'd.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] bash completion: teach fetch, pull, and push to complete their options
From: Shawn O. Pearce @ 2009-03-06 16:15 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Markus Heidelberg, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <5576c9f6e10a6efec0b2bbbd156a25852506cc49.1236314073.git.jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> wrote:
> fetch, pull, and push didn't know their options. They do now. merge's
> options are factored into a variable so they can be shared between
> _git_merge and _git_pull
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
but I think this patch depends on 2/3 in the series to be fixed first.
> ---
> contrib/completion/git-completion.bash | 61 +++++++++++++++++++++++++++++---
> 1 files changed, 56 insertions(+), 5 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-03-06 16:10 UTC (permalink / raw)
To: git
In-Reply-To: <eaa105840903051148s3515e8b7x9d7b8f9be12da735@mail.gmail.com>
On Thu, Mar 05, 2009 at 02:48:14PM -0500, Peter Harris wrote:
> On Thu, Mar 5, 2009 at 1:05 PM, Josef Wolf wrote:
> >
> > Well, actually it allows the changes for a very limited user group (that
> > is: only me 8-). While I agree that author/date should not be changed,
> > I like to be able to fix silly typos in the log. After all, we all do
> > typos now and then ;-)
>
> True, but in my experience it happens considerably less often with
> git. I find and fix most of my typos when reviewing my change-set
> before doing a "git push" or "git svn dcommit".
So you are rewriting yourself but not accept rewrites by svn ;-)
> > Maybe there's room for more improvement: Since the merge is done on a
> > scratch branch anyway, why not letting the clones _push_ into branches
> > with random names: cloneX-`uuidgen` or something. So the clones could
> > do the push whenever they have net access. The actual merge can be done
> > completely decoupled from the push operation.
>
> Indeed. Or even not-so-random names, such as cloneX/topic-name if you
> prefer.
That would have the risk of multiple clones pushing to the same branch.
I am not sure I am prepared to resolve such conflicts (yet). But you
are right, the branch name should contain the topic-name. So here's my
current favorite of the workflow:
# work on clone
#
(
cd clone$clone
# first move commits from subversion to clone
#
git checkout master
git pull --rebase
# do some work
#
git checkout -b topic-branch
for commit in 1 2 3; do
echo change $clone $commit >>test
git commit -a -m "commit $clone $commit"
done
# push the work
#
git push ../git-svn-repos topic-branch:clone-topic-branch-`uuidgen`
git checkout master
git branch -D topic-branch
)
# Integrate commits from clones an move them to subversion
#
(
cd git-svn-repos
for scratch in `git branch | grep ' clone-'` ; do
# merge client's work
#
git checkout $scratch
git svn rebase trunk
# resolve possible conflicts
#
grep change test >test.resolved
if diff test test.resolved ; then
rm test.resolved
else
mv test.resolved test
git add test
git commit -m "merge"
git rebase --skip
fi
# sync with svn repository
#
git svn dcommit
git checkout master
git svn rebase -l # fast-forward master to where scratch is
# clean up
#
git branch -d $scratch
done
)
Does that look sane?
The benefit is that work on clones and work on git-svn-repos is
decoupled.
^ permalink raw reply
* Re: [PATCH 2/3] bash completion: refactor --strategy completion
From: Jay Soffian @ 2009-03-06 16:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Markus Heidelberg, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <20090306160452.GH16213@spearce.org>
On Fri, Mar 6, 2009 at 11:04 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jay Soffian <jaysoffian@gmail.com> wrote:
>> The code to complete --strategy was duplicated between _git_rebase and
>> _git_merge, and is about to gain a third caller (_git_pull). This patch
>> factors it into its own function.
>>
>> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
>
> Looks OK to me, but I had to squash this in to get it to work.
> Without this the patch breaks git merge completion entirely:
Weird, I had it completely backwards but it seemed to work. Probably
because I was sourcing the new completion into my running shell; I'll
make sure to startup a new shell next time.
With the squash (assuming Junio doesn't mind), is it acked-by you or
should I resend?
j.
^ permalink raw reply
* [PATCH JGIT] Fix parsing peeled line in packed-ref
From: Daniel Cheng (aka SDiZ) @ 2009-03-06 16:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Daniel Cheng (aka SDiZ), Daniel Cheng (aka SDiZ)
From: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@sdiz.net>
When doing a WalkTransport with packed-ref, peeled
line are not handled correctly. This patch fix the issue.
Signed-off-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
---
.../jgit/transport/WalkRemoteObjectDatabase.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
index a4f8961..d8e727b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
@@ -436,7 +436,7 @@ private void readPackedRefsImpl(final Map<String, Ref> avail,
if (line.charAt(0) == '^') {
if (last == null)
throw new TransportException("Peeled line before ref.");
- final ObjectId id = ObjectId.fromString(line + 1);
+ final ObjectId id = ObjectId.fromString(line.substring(1));
last = new Ref(Ref.Storage.PACKED, last.getName(), last
.getObjectId(), id, true);
avail.put(last.getName(), last);
--
1.6.2.rc2
^ permalink raw reply related
* Re: [PATCH 2/3] bash completion: refactor --strategy completion
From: Shawn O. Pearce @ 2009-03-06 16:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Markus Heidelberg, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <2d83927582e9eed004b9fd12b77105a184277229.1236314073.git.jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> wrote:
> The code to complete --strategy was duplicated between _git_rebase and
> _git_merge, and is about to gain a third caller (_git_pull). This patch
> factors it into its own function.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Looks OK to me, but I had to squash this in to get it to work.
Without this the patch breaks git merge completion entirely:
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9e16576..80d464b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -449,15 +449,15 @@ __git_complete_strategy ()
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
__gitcomp "$(__git_merge_strategies)"
- return 1
+ return 0
esac
case "$cur" in
--strategy=*)
__gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
- return 1
+ return 0
;;
esac
- return 0
+ return 1
}
__git_all_commands ()
@@ -1111,9 +1111,8 @@ _git_log ()
_git_merge ()
{
- __git_complete_strategy && return
-
local cur="${COMP_WORDS[COMP_CWORD]}"
+ __git_complete_strategy && return
case "$cur" in
--*)
__gitcomp "
> ---
> contrib/completion/git-completion.bash | 37 ++++++++++++++++---------------
> 1 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index b347fdd..8924185 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -440,6 +440,22 @@ __git_complete_remote_or_refspec ()
> esac
> }
>
> +__git_complete_strategy ()
> +{
> + case "${COMP_WORDS[COMP_CWORD-1]}" in
> + -s|--strategy)
> + __gitcomp "$(__git_merge_strategies)"
> + return 1
> + esac
> + case "$cur" in
> + --strategy=*)
> + __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
> + return 1
> + ;;
> + esac
> + return 0
> +}
> +
> __git_all_commands ()
> {
> if [ -n "$__git_all_commandlist" ]; then
> @@ -1086,17 +1102,10 @@ _git_log ()
>
> _git_merge ()
> {
> + __git_complete_strategy && return
> +
> local cur="${COMP_WORDS[COMP_CWORD]}"
> - case "${COMP_WORDS[COMP_CWORD-1]}" in
> - -s|--strategy)
> - __gitcomp "$(__git_merge_strategies)"
> - return
> - esac
> case "$cur" in
> - --strategy=*)
> - __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
> - return
> - ;;
> --*)
> __gitcomp "
> --no-commit --no-stat --log --no-log --squash --strategy
> @@ -1165,16 +1174,8 @@ _git_rebase ()
> __gitcomp "--continue --skip --abort"
> return
> fi
> - case "${COMP_WORDS[COMP_CWORD-1]}" in
> - -s|--strategy)
> - __gitcomp "$(__git_merge_strategies)"
> - return
> - esac
> + __git_complete_strategy && return
> case "$cur" in
> - --strategy=*)
> - __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
> - return
> - ;;
> --*)
> __gitcomp "--onto --merge --strategy --interactive"
> return
> --
> 1.6.2.rc2.332.g5d21b
>
--
Shawn.
^ permalink raw reply related
* [PATCH GIT] Fix parsing peeled line in packed-ref
From: Daniel Cheng (aka SDiZ) @ 2009-03-06 16:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Daniel Cheng (aka SDiZ), Daniel Cheng (aka SDiZ)
From: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@sdiz.net>
When doing a WalkTransport with packed-ref, peeled
line are not handled correctly. This patch fix the issue.
Signed-off-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
---
.../jgit/transport/WalkRemoteObjectDatabase.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
index a4f8961..d8e727b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkRemoteObjectDatabase.java
@@ -436,7 +436,7 @@ private void readPackedRefsImpl(final Map<String, Ref> avail,
if (line.charAt(0) == '^') {
if (last == null)
throw new TransportException("Peeled line before ref.");
- final ObjectId id = ObjectId.fromString(line + 1);
+ final ObjectId id = ObjectId.fromString(line.substring(1));
last = new Ref(Ref.Storage.PACKED, last.getName(), last
.getObjectId(), id, true);
avail.put(last.getName(), last);
--
1.6.2.rc2
^ permalink raw reply related
* Re: [PATCH 1/3] bash completion: fix completion issues with fetch, pull, and push
From: Shawn O. Pearce @ 2009-03-06 15:58 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Markus Heidelberg, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <07bd381f7984117681504ce57c1f6c40aecafed3.1236314073.git.jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> wrote:
> Sverre Rabbelier noticed a completion issue with push:
>
> $ git push ori<tab>
> git push origin
>
> $ git push -f ori<tab>
> git push -f origin/
>
> Markus Heidelberg pointed out that the issue extends to fetch and pull.
>
> The reason is that the current code naively assumes that if
> COMP_CWORD=2, it should complete a remote name, otherwise it should
> complete a refspec. This assumption fails if there are any --options.
>
> This patch fixes that issue by instead scanning COMP_CWORDS to see if
> the remote has been completed yet (we now assume the first non-dashed
> argument is the remote). The new logic is factored into a function,
> shared by fetch, pull, and push.
>
> The new function also properly handles '.' as the remote.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> contrib/completion/git-completion.bash | 109 +++++++++++++++++--------------
> 1 files changed, 60 insertions(+), 49 deletions(-)
--
Shawn.
^ permalink raw reply
* [PATCH] git-p4: remove unnecessary semicolons at end of lines
From: Sam Hocevar @ 2009-03-06 15:53 UTC (permalink / raw)
To: git
This is a purely cosmetic patch that makes the git-p4 code look more
pythonish by getting rid of end-of-line semicolons.
git-p4: remove unnecessary semicolons at end of lines.
Signed-off-by: Sam Hocevar <sam@zoy.org>
---
contrib/fast-import/git-p4 | 46 ++++++++++++++++++++++----------------------
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3832f60..7ea5ac6 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -12,7 +12,7 @@ import optparse, sys, os, marshal, popen2, subprocess, shelve
import tempfile, getopt, sha, os.path, time, platform
import re
-from sets import Set;
+from sets import Set
verbose = False
@@ -240,7 +240,7 @@ def p4Cmd(cmd):
result = {}
for entry in list:
result.update(entry)
- return result;
+ return result
def p4Where(depotPath):
if not depotPath.endswith("/"):
@@ -281,7 +281,7 @@ def currentGitBranch():
def isValidGitDir(path):
if (os.path.exists(path + "/HEAD")
and os.path.exists(path + "/refs") and os.path.exists(path + "/objects")):
- return True;
+ return True
return False
def parseRevision(ref):
@@ -328,8 +328,8 @@ def extractSettingsGitLog(log):
def gitBranchExists(branch):
proc = subprocess.Popen(["git", "rev-parse", branch],
- stderr=subprocess.PIPE, stdout=subprocess.PIPE);
- return proc.wait() == 0;
+ stderr=subprocess.PIPE, stdout=subprocess.PIPE)
+ return proc.wait() == 0
_gitConfig = {}
def gitConfig(key):
@@ -492,7 +492,7 @@ class P4RollBack(Command):
maxChange = int(args[0])
if "p4ExitCode" in p4Cmd("changes -m 1"):
- die("Problems executing p4");
+ die("Problems executing p4")
if self.rollbackLocalBranches:
refPrefix = "refs/heads/"
@@ -663,7 +663,7 @@ class P4Submit(Command):
if response == "s":
print "Skipping! Good luck with the next patches..."
for f in editedFiles:
- p4_system("revert \"%s\"" % f);
+ p4_system("revert \"%s\"" % f)
for f in filesToAdd:
system("rm %s" %f)
return
@@ -734,7 +734,7 @@ class P4Submit(Command):
if os.environ.has_key("P4EDITOR"):
editor = os.environ.get("P4EDITOR")
else:
- editor = os.environ.get("EDITOR", defaultEditor);
+ editor = os.environ.get("EDITOR", defaultEditor)
system(editor + " " + fileName)
response = "y"
@@ -753,9 +753,9 @@ class P4Submit(Command):
p4_write_pipe("submit -i", submitTemplate)
else:
for f in editedFiles:
- p4_system("revert \"%s\"" % f);
+ p4_system("revert \"%s\"" % f)
for f in filesToAdd:
- p4_system("revert \"%s\"" % f);
+ p4_system("revert \"%s\"" % f)
system("rm %s" %f)
os.remove(fileName)
@@ -977,9 +977,9 @@ class P4Sync(Command):
if "p4ExitCode" in filedata[0]:
die("Problems executing p4. Error: [%d]."
- % (filedata[0]['p4ExitCode']));
+ % (filedata[0]['p4ExitCode']))
- j = 0;
+ j = 0
contents = {}
while j < len(filedata):
stat = filedata[j]
@@ -1303,8 +1303,8 @@ class P4Sync(Command):
def importNewBranch(self, branch, maxChange):
# make fast-import flush all changes to disk and update the refs using the checkpoint
# command so that we can try to find the branch parent in the git history
- self.gitStream.write("checkpoint\n\n");
- self.gitStream.flush();
+ self.gitStream.write("checkpoint\n\n")
+ self.gitStream.flush()
branchPrefix = self.depotPaths[0] + branch + "/"
range = "@1,%s" % maxChange
#print "prefix" + branchPrefix
@@ -1364,12 +1364,12 @@ class P4Sync(Command):
fullBranch = self.projectName + branch
if fullBranch not in self.p4BranchesInGit:
if not self.silent:
- print("\n Importing new branch %s" % fullBranch);
+ print("\n Importing new branch %s" % fullBranch)
if self.importNewBranch(branch, change - 1):
parent = ""
self.p4BranchesInGit.append(fullBranch)
if not self.silent:
- print("\n Resuming with change %s" % change);
+ print("\n Resuming with change %s" % change)
if self.verbose:
print "parent determined through known branches: %s" % parent
@@ -1485,7 +1485,7 @@ class P4Sync(Command):
self.branch = self.refPrefix + "master"
if gitBranchExists("refs/heads/p4") and self.importIntoRemotes:
system("git update-ref %s refs/heads/p4" % self.branch)
- system("git branch -D p4");
+ system("git branch -D p4")
# create it /after/ importing, when master exists
if not gitBranchExists(self.refPrefix + "HEAD") and self.importIntoRemotes and gitBranchExists(self.branch):
system("git symbolic-ref %sHEAD %s" % (self.refPrefix, self.branch))
@@ -1591,7 +1591,7 @@ class P4Sync(Command):
self.loadUserMapFromCache()
self.labels = {}
if self.detectLabels:
- self.getLabels();
+ self.getLabels()
if self.detectBranches:
## FIXME - what's a P4 projectName ?
@@ -1615,7 +1615,7 @@ class P4Sync(Command):
importProcess = subprocess.Popen(["git", "fast-import"],
stdin=subprocess.PIPE, stdout=subprocess.PIPE,
- stderr=subprocess.PIPE);
+ stderr=subprocess.PIPE)
self.gitOutput = importProcess.stdout
self.gitStream = importProcess.stdin
self.gitError = importProcess.stderr
@@ -1688,9 +1688,9 @@ class P4Rebase(Command):
def rebase(self):
if os.system("git update-index --refresh") != 0:
- die("Some files in your working directory are modified and different than what is in your index. You can use git update-index <filename> to bring the index up-to-date or stash away all your changes with git stash.");
+ die("Some files in your working directory are modified and different than what is in your index. You can use git update-index <filename> to bring the index up-to-date or stash away all your changes with git stash.")
if len(read_pipe("git diff-index HEAD --")) > 0:
- die("You have uncommited changes. Please commit them before rebasing or stash them away with git stash.");
+ die("You have uncommited changes. Please commit them before rebasing or stash them away with git stash.")
[upstream, settings] = findUpstreamBranchPoint()
if len(upstream) == 0:
@@ -1866,7 +1866,7 @@ def main():
description = cmd.description,
formatter = HelpFormatter())
- (cmd, args) = parser.parse_args(sys.argv[2:], cmd);
+ (cmd, args) = parser.parse_args(sys.argv[2:], cmd)
global verbose
verbose = cmd.verbose
if cmd.needsGit:
@@ -1877,7 +1877,7 @@ def main():
if os.path.exists(cmd.gitdir):
cdup = read_pipe("git rev-parse --show-cdup").strip()
if len(cdup) > 0:
- chdir(cdup);
+ chdir(cdup)
if not isValidGitDir(cmd.gitdir):
if isValidGitDir(cmd.gitdir + "/.git"):
--
Sam.
^ permalink raw reply related
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