* Re: Using the --track option when creating a branch
From: Samuel Tardieu @ 2008-10-30 13:52 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bill Lear, git
In-Reply-To: <4909A7C4.30507@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
Andreas> This particular bikeshed was painted a long time ago, with
Andreas> the consensus going in favour of "git push" pushing all
Andreas> *matching* refspecs.
I still don't understand why this is useful, especially when git push
already has a "--all" option.
I know that I've never had the intent to push all the refs without
thinking about it first. Most of the time, I intend to push only
the current branch I am in.
The current behaviour made me remove the branches I was not actively
on locally, because I would get errors from "git push" all the time
saying that I was not up-to-date in those branches.
Note that the "git pull" issue is completely different, as it merges
or fast forwards the current branch only.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Andreas Ericsson @ 2008-10-30 14:06 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Bill Lear, git
In-Reply-To: <2008-10-30-14-52-52+trackit+sam@rfc1149.net>
Samuel Tardieu wrote:
>>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
>
> Andreas> This particular bikeshed was painted a long time ago, with
> Andreas> the consensus going in favour of "git push" pushing all
> Andreas> *matching* refspecs.
>
> I still don't understand why this is useful, especially when git push
> already has a "--all" option.
>
--all pushes all refs, even the non-matching ones, which is very
rarely desirable and only accidentally sometimes the same as "push all
matching refs".
> I know that I've never had the intent to push all the refs without
> thinking about it first. Most of the time, I intend to push only
> the current branch I am in.
>
Then say so. There's a very simple command syntax for it:
"git push <remote> <current-branch>"
> The current behaviour made me remove the branches I was not actively
> on locally, because I would get errors from "git push" all the time
> saying that I was not up-to-date in those branches.
>
That's an orthogonal issue, and one that really could be fixed without
anyone complaining. Send a patch that checks if foo is a strict subset
of <remote>/foo before trying to send it, and abort if it is so. This
means that we'll try to push "foo" if upstream rewrote their "foo", but
perhaps that's just as well.
Note though that the patch mustn't try to apply any smarts if a ref is
given explicitly.
> Note that the "git pull" issue is completely different, as it merges
> or fast forwards the current branch only.
>
"git pull" is actually only vaguely connected with "git push". The
opposite of "push" is "fetch" in git lingo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Samuel Tardieu @ 2008-10-30 14:23 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bill Lear, git
In-Reply-To: <4909BF58.9010500@op5.se>
* Andreas Ericsson <ae@op5.se> [2008-10-30 15:06:16 +0100]
> --all pushes all refs, even the non-matching ones, which is very
> rarely desirable and only accidentally sometimes the same as "push all
> matching refs".
>
>> I know that I've never had the intent to push all the refs without
>> thinking about it first. Most of the time, I intend to push only
>> the current branch I am in.
>
> Then say so. There's a very simple command syntax for it:
> "git push <remote> <current-branch>"
I update the branches I'm working in maybe 20 times a day, sometimes
more. When I make a change and all the tests pass, I prefer to call
git push
rather than
git push origin 2.0-beta1
(and "2.0-beta1" is a short name here, some branches have much longer
names)
I think it would be better to have :
git push <= push the current branch
git push --all <= push all matching refs
git push --all --create <= push all matching refs, create if needed
The latest command is probably used so rarely (compared to the others)
that it wouldn't be a problem to make it longer. Of course, if a
refspec is given explicitely, it should be honored and remote refs
created if needed.
I am curious of what other people workflows are. Do you often push
multiple branches at the same time? More often than one at a time?
Many times a day?
> "git pull" is actually only vaguely connected with "git push". The
> opposite of "push" is "fetch" in git lingo.
I know, but "git fetch" only updates remote tracking branches, and I
think that in the majority of the cases you want to advance all the
remote references. And even if you screw up, the problem will only
happen in your local copy, not in an upstream or shared repository.
I assume that most people "push" to public repositories and not
many of them "pull" into public repositories directly.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Nicolas Pitre @ 2008-10-30 14:34 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net>
On Wed, 29 Oct 2008, Sam Vilain wrote:
> From: Sam Vilain <samv@vilain.net>
>
> For cross-command CLI changes to be effective, they need to be
> cohesively planned. Add a planning document for this next set of
> changes.
>
> Signed-off-by: Sam Vilain <sam@vilain.net>
[...]
> + * 'git checkout branch' would, if there is a remote branch called
> + 'branch' on exactly one remote, do what
> + 'git checkout -b branch thatremote/branch' does now. If it is
> + ambiguous, it would be an error, forcing the explicit notation.
I can't do otherwise but disagree with this. Currently, when a remote
branch is checked out, the commit corresponding to that remote branch is
put on a detached head which is IMHO completely sane and coherent. It
even tells you how to create a local branch from there if that's what
you wanted to do. So if it is still too confusing at that point then
more explanations are needed and not the removal of a perfectly fine
feature. Please don't change that behavior.
Nicolas
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Theodore Tso @ 2008-10-30 14:39 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Sam Vilain
In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net>
On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:
> From: Sam Vilain <samv@vilain.net>
>
> For cross-command CLI changes to be effective, they need to be
> cohesively planned. Add a planning document for this next set of
> changes.
Here are my favorites:
* Add the command "git revert-file <files>" which is syntactic sugar for:
git checkout HEAD -- <files>
Rationale: Many other SCM's have a way of undoing local edits to a
file very simply, i.e."hg revert <file>" or "svn revert <file>", and
for many developers's workflow, it's useful to be able to undo local
edits to a single file, but not to everything else in the working
directory. And "git checkout HEAD -- <file>" is rather cumbersome
to type, and many beginning users don't find it intuitive to look in
the "git-checkout" man page for instructions on how to revert a
local file.
* Change the argument handling for "git format-patch" so it is
consistent with everything else which takes a set of commits. Yes,
it means that where people have gotten used to typing "git
format-patch origin", they'll have to type instead: "git
format-patch origin..", but's much more consistent. We've done the
best we can by documenting the existing behavior, but if'we re going
to make major, potentially incompatible, CLI changes, this is
something to at least consider. Maybe with a config file for people
who really don't want to retrain their fingers to type the two extra
periods?
- Ted
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Pierre Habouzit @ 2008-10-30 14:41 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Andreas Ericsson, Bill Lear, git
In-Reply-To: <2008-10-30-15-23-16+trackit+sam@rfc1149.net>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:
> I think it would be better to have :
>
> git push <= push the current branch
> git push --all <= push all matching refs
> git push --all --create <= push all matching refs, create if needed
>
> The latest command is probably used so rarely (compared to the others)
> that it wouldn't be a problem to make it longer. Of course, if a
> refspec is given explicitely, it should be honored and remote refs
> created if needed.
Fwiw I'm in favor of that, and it was what I advocated at the time.
Though I think than as soon as you add an explicit remote name, like:
git push origin, pushing all matched references makes sense. Which is
also what I advocated at the time.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-10-30 14:43 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030143918.GB14744@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]
On Thu, Oct 30, 2008 at 02:39:18PM +0000, Theodore Tso wrote:
> On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:
> > From: Sam Vilain <samv@vilain.net>
> >
> > For cross-command CLI changes to be effective, they need to be
> > cohesively planned. Add a planning document for this next set of
> > changes.
>
> Here are my favorites:
>
> * Add the command "git revert-file <files>" which is syntactic sugar for:
>
> git checkout HEAD -- <files>
>
> Rationale: Many other SCM's have a way of undoing local edits to a
> file very simply, i.e."hg revert <file>" or "svn revert <file>", and
> for many developers's workflow, it's useful to be able to undo local
> edits to a single file, but not to everything else in the working
> directory. And "git checkout HEAD -- <file>" is rather cumbersome
> to type, and many beginning users don't find it intuitive to look in
> the "git-checkout" man page for instructions on how to revert a
> local file.
This is what is currently proposed for undo, but yeah, revert-file or
maybe rather revert-changes may be suitable.
> * Change the argument handling for "git format-patch" so it is
> consistent with everything else which takes a set of commits. Yes,
> it means that where people have gotten used to typing "git
> format-patch origin", they'll have to type instead: "git
> format-patch origin..", but's much more consistent. We've done the
> best we can by documenting the existing behavior, but if'we re going
> to make major, potentially incompatible, CLI changes, this is
> something to at least consider. Maybe with a config file for people
> who really don't want to retrain their fingers to type the two extra
> periods?
git format-patch origin/next.. works already. I'm used to the asymetric
git format-patch origin/next syntax, and I would be sorry if it
disappeared though, and I see no really good reason to get rid of it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Shawn O. Pearce @ 2008-10-30 14:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sam Vilain, git
In-Reply-To: <alpine.LFD.2.00.0810301024300.13034@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 29 Oct 2008, Sam Vilain wrote:
> > From: Sam Vilain <samv@vilain.net>
> >
> > For cross-command CLI changes to be effective, they need to be
> > cohesively planned. Add a planning document for this next set of
> > changes.
> >
> > Signed-off-by: Sam Vilain <sam@vilain.net>
> [...]
>
> > + * 'git checkout branch' would, if there is a remote branch called
> > + 'branch' on exactly one remote, do what
> > + 'git checkout -b branch thatremote/branch' does now. If it is
> > + ambiguous, it would be an error, forcing the explicit notation.
>
> I can't do otherwise but disagree with this. Currently, when a remote
> branch is checked out, the commit corresponding to that remote branch is
> put on a detached head which is IMHO completely sane and coherent. It
> even tells you how to create a local branch from there if that's what
> you wanted to do. So if it is still too confusing at that point then
> more explanations are needed and not the removal of a perfectly fine
> feature. Please don't change that behavior.
+1 to Nico's NAK.
Although I was at the GitTogether I don't remember this change to
checkout being discussed. I must have been asleep reading email
or something. I am _NOT_ in favor of this change; I think the
current behavior of "git checkout origin/master" is correct and as
sane as we can make it.
--
Shawn.
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Andreas Ericsson @ 2008-10-30 14:54 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Bill Lear, git
In-Reply-To: <2008-10-30-15-23-16+trackit+sam@rfc1149.net>
Samuel Tardieu wrote:
> * Andreas Ericsson <ae@op5.se> [2008-10-30 15:06:16 +0100]
>
>> --all pushes all refs, even the non-matching ones, which is very
>> rarely desirable and only accidentally sometimes the same as "push all
>> matching refs".
>>
>>> I know that I've never had the intent to push all the refs without
>>> thinking about it first. Most of the time, I intend to push only
>>> the current branch I am in.
>> Then say so. There's a very simple command syntax for it:
>> "git push <remote> <current-branch>"
>
> I update the branches I'm working in maybe 20 times a day, sometimes
> more. When I make a change and all the tests pass, I prefer to call
>
> git push
>
> rather than
>
> git push origin 2.0-beta1
>
So why don't you? Unless you also make lots of changes on other branches,
the two commands will result in exactly the same thing.
> (and "2.0-beta1" is a short name here, some branches have much longer
> names)
>
> I think it would be better to have :
>
> git push <= push the current branch
> git push --all <= push all matching refs
> git push --all --create <= push all matching refs, create if needed
>
Correct me if I'm wrong, but wouldn't my suggestion of not trying to
push (even matching) branches that haven't been updated since we last
fetched from the remote do exactly the same thing for your particular
use-case, but without syntax change and all the annoying minor parts
that it entails?
> The latest command is probably used so rarely (compared to the others)
> that it wouldn't be a problem to make it longer. Of course, if a
> refspec is given explicitely, it should be honored and remote refs
> created if needed.
>
> I am curious of what other people workflows are. Do you often push
> multiple branches at the same time?
Quite often, yes.
> More often than one at a time?
No.
> Many times a day?
>
Define "many". Perhaps as often as 2-3 times per day. Not very often,
but frequent enough that I definitely want some short sweet way of
doing it. OTOH, I also find the "rejected" messages annoying, and I
definitely feel one could do something about them. However, it's my
birthday today and I plan on being far too drunk/hungover the entire
weekend for me to take any actions in that direction.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Samuel Tardieu @ 2008-10-30 14:56 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Andreas Ericsson, Bill Lear, git
In-Reply-To: <20081030144107.GE24098@artemis.corp>
* Pierre Habouzit <madcoder@debian.org> [2008-10-30 15:41:07 +0100]
| On Thu, Oct 30, 2008 at 02:23:16PM +0000, Samuel Tardieu wrote:
| > I think it would be better to have :
| >
| > git push <= push the current branch
| > git push --all <= push all matching refs
| > git push --all --create <= push all matching refs, create if needed
| >
| > The latest command is probably used so rarely (compared to the others)
| > that it wouldn't be a problem to make it longer. Of course, if a
| > refspec is given explicitely, it should be honored and remote refs
| > created if needed.
|
| Fwiw I'm in favor of that, and it was what I advocated at the time.
|
| Though I think than as soon as you add an explicit remote name, like:
| git push origin, pushing all matched references makes sense. Which is
| also what I advocated at the time.
Indeed, it makes sense. We could then have:
git push <= push the current branch on default remote
(which is, at least in my case, the most
frequent use I want to make of "git push",
on all the projects [work or volunteer]
I work on)
git push remote <= push all matching refs on named remote
git push --all [remote] <= push and create all refs on remote (or default)
Sam
^ permalink raw reply
* Re: [StGit PATCH 1/3] stgit.el: Added undo command
From: David Kågedal @ 2008-10-30 14:57 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, catalin marinas
In-Reply-To: <20081030115716.GA19360@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2008-10-30 10:52:48 +0100, David Kågedal wrote:
>
>> Bound it to the two standard bindings C-/ and C-_.
>
>> + (define-key stgit-mode-map [(control ?/)] 'stgit-undo)
>> + (define-key stgit-mode-map "\C-_" 'stgit-undo))
>
> Hmm, why do you spell control in two different ways?
I usually use the "\C-x" syntax, but for some reason that didn't work
with "\C-/", so I used another syntax. I'm not sure how compatible
that is with XEmacs, though.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Mike Hommey @ 2008-10-30 14:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, Sam Vilain, git
In-Reply-To: <20081030145253.GK14786@spearce.org>
On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce <spearce@spearce.org> wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Wed, 29 Oct 2008, Sam Vilain wrote:
> > > From: Sam Vilain <samv@vilain.net>
> > >
> > > For cross-command CLI changes to be effective, they need to be
> > > cohesively planned. Add a planning document for this next set of
> > > changes.
> > >
> > > Signed-off-by: Sam Vilain <sam@vilain.net>
> > [...]
> >
> > > + * 'git checkout branch' would, if there is a remote branch called
> > > + 'branch' on exactly one remote, do what
> > > + 'git checkout -b branch thatremote/branch' does now. If it is
> > > + ambiguous, it would be an error, forcing the explicit notation.
> >
> > I can't do otherwise but disagree with this. Currently, when a remote
> > branch is checked out, the commit corresponding to that remote branch is
> > put on a detached head which is IMHO completely sane and coherent. It
> > even tells you how to create a local branch from there if that's what
> > you wanted to do. So if it is still too confusing at that point then
> > more explanations are needed and not the removal of a perfectly fine
> > feature. Please don't change that behavior.
>
> +1 to Nico's NAK.
>
> Although I was at the GitTogether I don't remember this change to
> checkout being discussed. I must have been asleep reading email
> or something. I am _NOT_ in favor of this change; I think the
> current behavior of "git checkout origin/master" is correct and as
> sane as we can make it.
Except he was talking about 'git checkout branch', not 'git checkout
origin/branch'. And I would be fine with 'git checkout branch' doing
what 'git checkout -b branch $remote/branch' does if $remote is unique
(i.e. there is no other 'branch' branch in any other remote) and the
'branch' branch doesn't already exist.
Mike
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-10-30 15:01 UTC (permalink / raw)
To: Mike Hommey; +Cc: Shawn O. Pearce, Nicolas Pitre, Sam Vilain, git
In-Reply-To: <20081030145928.GA21707@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]
On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote:
> On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce <spearce@spearce.org> wrote:
> > +1 to Nico's NAK.
> >
> > Although I was at the GitTogether I don't remember this change to
> > checkout being discussed. I must have been asleep reading email
> > or something. I am _NOT_ in favor of this change; I think the
> > current behavior of "git checkout origin/master" is correct and as
> > sane as we can make it.
>
> Except he was talking about 'git checkout branch', not 'git checkout
> origin/branch'. And I would be fine with 'git checkout branch' doing
> what 'git checkout -b branch $remote/branch' does if $remote is unique
> (i.e. there is no other 'branch' branch in any other remote) and the
> 'branch' branch doesn't already exist.
Seconded.
Having git-checkout $foo being a shorthand for git checkout -b $foo
origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Andreas Ericsson @ 2008-10-30 15:02 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030143918.GB14744@mit.edu>
Theodore Tso wrote:
> On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:
>> From: Sam Vilain <samv@vilain.net>
>>
>> For cross-command CLI changes to be effective, they need to be
>> cohesively planned. Add a planning document for this next set of
>> changes.
>
> Here are my favorites:
>
> * Add the command "git revert-file <files>" which is syntactic sugar for:
>
> git checkout HEAD -- <files>
>
> Rationale: Many other SCM's have a way of undoing local edits to a
> file very simply, i.e."hg revert <file>" or "svn revert <file>", and
> for many developers's workflow, it's useful to be able to undo local
> edits to a single file, but not to everything else in the working
> directory. And "git checkout HEAD -- <file>" is rather cumbersome
> to type, and many beginning users don't find it intuitive to look in
> the "git-checkout" man page for instructions on how to revert a
> local file.
>
I like it, although I guess one would have to add a "--staged" flag to
git revert-file to be able to checkout files from index as well, or people
will wonder why that can't be done.
> * Change the argument handling for "git format-patch" so it is
> consistent with everything else which takes a set of commits. Yes,
> it means that where people have gotten used to typing "git
> format-patch origin", they'll have to type instead: "git
> format-patch origin..", but's much more consistent. We've done the
> best we can by documenting the existing behavior, but if'we re going
> to make major, potentially incompatible, CLI changes, this is
> something to at least consider. Maybe with a config file for people
> who really don't want to retrain their fingers to type the two extra
> periods?
>
"git format-patch" does exactly the same thing as other commit-range handling
commands do, which is assume that the missing commit end-point is HEAD, so it
actually is consistent, although it doesn't quite look as if it is.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Samuel Tardieu @ 2008-10-30 15:04 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bill Lear, git
In-Reply-To: <4909CABD.1040708@op5.se>
* Andreas Ericsson <ae@op5.se> [2008-10-30 15:54:53 +0100]
> Correct me if I'm wrong, but wouldn't my suggestion of not trying to
> push (even matching) branches that haven't been updated since we last
> fetched from the remote do exactly the same thing for your particular
> use-case, but without syntax change and all the annoying minor parts
> that it entails?
Not exactly. I often do some work on a branch which does not mandate
a topic branch and have to switch branches to fix a bug for example.
This would continue to push unterminated changes as well.
Typical use case, which happens (to me) quite frequently:
% git checkout master
[start new feature, estimated implementation time 15 minutes]
% git commit -m "Reorganize foobar in previous of xyzzy."
(note that I'm not sure that I will keep it, I'll know that later
when my next commit is ready, maybe in 10 minutes, no need for
a topic branch)
[mail from a customer, "I noticed some strange behaviour here" --
let's fix it]
% git checkout 2.0-beta1-release-candidate
[fix strange behaviour and add new test]
[test locally]
% git commit -m "Fix strange behaviour baz."
% git push
(so that it goes to the buildfarm for QA testing)
Argh, "master" has been pushed as well. Ok, I could have done
% git branch
(because I know I am on the right branch but do not necessarily
remember its full name all the time)
% git push origin 2.0-beta1-release-candidate
or I could have started a topic branch, but I often push 2 or 3
commits at a time instead, the first one being a refactoring of
existing code to ease the subsequent one.
>From what I have seen, people I am working with often have the
same workflow (do not systematically start a topic branch when
in active development mode)
> Define "many". Perhaps as often as 2-3 times per day. Not very often,
> but frequent enough that I definitely want some short sweet way of
> doing it. OTOH, I also find the "rejected" messages annoying, and I
> definitely feel one could do something about them. However, it's my
> birthday today and I plan on being far too drunk/hungover the entire
> weekend for me to take any actions in that direction.
Happy birthday :)
^ permalink raw reply
* Re: [PATCH] git-filter-branch: Add an example on how to remove empty commits
From: Deskin Miller @ 2008-10-30 15:06 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Petr Baudis, git, Sverre Rabbelier
In-Reply-To: <20081030132623.GC24098@artemis.corp>
On Thu, Oct 30, 2008 at 02:26:23PM +0100, Pierre Habouzit wrote:
> Why not add an option to filter-branch that removes a commit if it's
> empty ? It's quite useful, it helps the user concentrating on just
> keeping what matches *his* criteriums, and not caring about the minor
> details of cleansing the result.
I've thought this would be useful at times myself. One potential complication,
however, is that the history could come from a SVN repository via git-svn, in
which case it's possible that empty commits exist due to an incomplete mapping
of SVN's changes, e.g. SVN property changes will get their own revision, even
if the file content does not change.
Therefore, if one were to write a patch such as Pierre suggests, I'd strongly
suggest checking the commit message first for any git-svn-id: line, and either
refusing to work without some --force option from the user, or giving a strong
warning to the user that their git-svn setup may not work properly any more,
and clear instructions on how to recover those refs, or update the svn-related
metadata.
On further thought, automatically updating the svn metadata might be useful to
add as an option to filter-branch regardless; I'll think about that some
myself, any thoughts from others?
My $0.02,
Deskin Miller
^ permalink raw reply
* Re: [PATCH] git-filter-branch: Add an example on how to remove empty commits
From: Pierre Habouzit @ 2008-10-30 15:10 UTC (permalink / raw)
To: Deskin Miller; +Cc: Petr Baudis, git, Sverre Rabbelier
In-Reply-To: <20081030150617.GA14098@euler>
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
On Thu, Oct 30, 2008 at 03:06:18PM +0000, Deskin Miller wrote:
> On Thu, Oct 30, 2008 at 02:26:23PM +0100, Pierre Habouzit wrote:
> > Why not add an option to filter-branch that removes a commit if it's
> > empty ? It's quite useful, it helps the user concentrating on just
> > keeping what matches *his* criteriums, and not caring about the minor
> > details of cleansing the result.
>
> I've thought this would be useful at times myself. One potential complication,
> however, is that the history could come from a SVN repository via git-svn, in
> which case it's possible that empty commits exist due to an incomplete mapping
> of SVN's changes, e.g. SVN property changes will get their own revision, even
> if the file content does not change.
Well, if you want to migrate your git-svn repository to something else,
it doesn't makes sense to add this limitation. I'd rather see this
"problem" advertized in the manual page, rather than a limitation added.
Note that using git filter-branch on a git-svn repository and still
expecting it to work with git-svn is IMHO wrong in so many ways that we
should not really try that hard to prevent the user doing something
stupid anyways.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Encoding problems using git-svn
From: James North @ 2008-10-30 15:14 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20081030074114.GA26926@yp-box.dyndns.org>
Hi Eric,
Don't worry about not seeing the patch and thanks for the answer :)
Your patch works great.
Messages appear without problems on "svn log" and "git log", I haven't
found any gotcha that I know of.
The weird thing is that this problem was not found by anyone before, I
guessed there should be some people with a setup similar to mine.
Thanks again.
On Thu, Oct 30, 2008 at 8:41 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Hi James,
>
> I saw your other patch too late, I had already started working on my
> patch earlier today but got distracted by other things (being at
> GitTogether :) and lacked a stable Internet connection afterwards.
>
> Anyways, here's my version, it handles the case where the user specifies
> the --edit option to interactively edit the commit message before
> committing; and also reencodes the messages when fetching from SVN.
>
> Can you let me know if it works for you?
>
> Note: I'll be in transit tomorrow and may not have time to follow
> up on this until Saturday.
>
> From 84f003e0c39414ebf27a98de167643e95bed6abb Mon Sep 17 00:00:00 2001
> From: Eric Wong <normalperson@yhbt.net>
> Date: Wed, 29 Oct 2008 23:49:26 -0700
> Subject: [PATCH] git-svn: respect i18n.commitencoding config
>
> SVN itself always stores log messages in the repository as
> UTF-8. git always stores/retrieves everything as raw binary
> data with no transformations whatsoever.
>
> To interact with SVN, we need to encode log messages as UTF-8
> before sending them to SVN, as SVN cannot do it for us. When
> retrieving log messages from SVN, we also need to (attempt to)
> reencode the UTF-8 log message back to the user-specified commit
> encoding.
>
> Note, handling i18n.logoutputencoding for "git svn log" also
> needs to be done in a future change.
>
> Also, this change only deals with the encoding of commit
> messages and nothing else (path names, blob content, ...).
>
> In-Reply-To: <8b168cfb0810282014r789ac01dnec51824de1078f0@mail.gmail.com>
> James North <tocapicha@gmail.com> wrote:
>> Hi,
>>
>> I'm using git-svn on a system with ISO-8859-1 encoding. The problem is
>> when I try to use "git svn dcommit" to send changes to a remote svn
>> (also ISO-8859-1).
>>
>> Seems like git-svn is sending commit messages with utf-8 (just a
>> guessing...) and they look bad on the remote svn log. E.g. "Ca?\241a
>> de cami?\243n"
>>
>> I have tried using i18n.commitencoding=ISO-8859-1 as suggested by the
>> warning when doing "git svn dcommit" but messages still are sent with
>> wrong encoding.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
> git-svn.perl | 24 ++++++++-
> t/t9129-git-svn-i18n-commitencoding.sh | 80 ++++++++++++++++++++++++++++++++
> 2 files changed, 101 insertions(+), 3 deletions(-)
> create mode 100755 t/t9129-git-svn-i18n-commitencoding.sh
>
> diff --git a/git-svn.perl b/git-svn.perl
> index f90ddac..f24559c 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1136,9 +1136,19 @@ sub get_commit_entry {
> system($editor, $commit_editmsg);
> }
> rename $commit_editmsg, $commit_msg or croak $!;
> - open $log_fh, '<', $commit_msg or croak $!;
> - { local $/; chomp($log_entry{log} = <$log_fh>); }
> - close $log_fh or croak $!;
> + {
> + # SVN requires messages to be UTF-8 when entering the repo
> + local $/;
> + open $log_fh, '<', $commit_msg or croak $!;
> + binmode $log_fh;
> + chomp($log_entry{log} = <$log_fh>);
> +
> + if (my $enc = Git::config('i18n.commitencoding')) {
> + require Encode;
> + Encode::from_to($log_entry{log}, $enc, 'UTF-8');
> + }
> + close $log_fh or croak $!;
> + }
> unlink $commit_msg;
> \%log_entry;
> }
> @@ -2273,6 +2283,14 @@ sub do_git_commit {
> }
> defined(my $pid = open3(my $msg_fh, my $out_fh, '>&STDERR', @exec))
> or croak $!;
> + binmode $msg_fh;
> +
> + # we always get UTF-8 from SVN, but we may want our commits in
> + # a different encoding.
> + if (my $enc = Git::config('i18n.commitencoding')) {
> + require Encode;
> + Encode::from_to($log_entry->{log}, 'UTF-8', $enc);
> + }
> print $msg_fh $log_entry->{log} or croak $!;
> restore_commit_header_env($old_env);
> unless ($self->no_metadata) {
> diff --git a/t/t9129-git-svn-i18n-commitencoding.sh b/t/t9129-git-svn-i18n-commitencoding.sh
> new file mode 100755
> index 0000000..2848e46
> --- /dev/null
> +++ b/t/t9129-git-svn-i18n-commitencoding.sh
> @@ -0,0 +1,80 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2008 Eric Wong
> +
> +test_description='git svn honors i18n.commitEncoding in config'
> +
> +. ./lib-git-svn.sh
> +
> +compare_git_head_with () {
> + nr=`wc -l < "$1"`
> + a=7
> + b=$(($a + $nr - 1))
> + git cat-file commit HEAD | sed -ne "$a,${b}p" >current &&
> + test_cmp current "$1"
> +}
> +
> +compare_svn_head_with () {
> + LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
> + sed -e 1,3d -e "/^-\+\$/d" >current &&
> + test_cmp current "$1"
> +}
> +
> +for H in ISO-8859-1 EUCJP ISO-2022-JP
> +do
> + test_expect_success "$H setup" '
> + mkdir $H &&
> + svn import -m "$H test" $H "$svnrepo"/$H &&
> + git svn clone "$svnrepo"/$H $H
> + '
> +done
> +
> +for H in ISO-8859-1 EUCJP ISO-2022-JP
> +do
> + test_expect_success "$H commit on git side" '
> + (
> + cd $H &&
> + git config i18n.commitencoding $H &&
> + git checkout -b t refs/remotes/git-svn &&
> + echo $H >F &&
> + git add F &&
> + git commit -a -F "$TEST_DIRECTORY"/t3900/$H.txt &&
> + E=$(git cat-file commit HEAD | sed -ne "s/^encoding //p") &&
> + test "z$E" = "z$H"
> + compare_git_head_with "$TEST_DIRECTORY"/t3900/$H.txt
> + )
> + '
> +done
> +
> +for H in ISO-8859-1 EUCJP ISO-2022-JP
> +do
> + test_expect_success "$H dcommit to svn" '
> + (
> + cd $H &&
> + git svn dcommit &&
> + git cat-file commit HEAD | grep git-svn-id: &&
> + E=$(git cat-file commit HEAD | sed -ne "s/^encoding //p") &&
> + test "z$E" = "z$H" &&
> + compare_git_head_with "$TEST_DIRECTORY"/t3900/$H.txt
> + )
> + '
> +done
> +
> +test_expect_success 'ISO-8859-1 should match UTF-8 in svn' '
> +(
> + cd ISO-8859-1 &&
> + compare_svn_head_with "$TEST_DIRECTORY"/t3900/1-UTF-8.txt
> +)
> +'
> +
> +for H in EUCJP ISO-2022-JP
> +do
> + test_expect_success '$H should match UTF-8 in svn' '
> + (
> + cd $H &&
> + compare_svn_head_with "$TEST_DIRECTORY"/t3900/2-UTF-8.txt
> + )
> + '
> +done
> +
> +test_done
> --
> Eric Wong
>
^ permalink raw reply
* [BUG] git log --walk-reflogs --pretty=oneline --all
From: Leo Razoumov @ 2008-10-30 15:19 UTC (permalink / raw)
To: Git Mailing List
Take a test repository that already has several commits in it, do the
following and watch the results:
sh$ git reflog expire --expire=1.second.ago --all
sh$ git log --walk-reflogs --pretty=oneline --all
I am using git-1.6.0.2 and that's what I get
sh$ git reflog expire --expire=1.second.ago --all
sh$ git log --walk-reflogs --pretty=oneline --all
60684d9df4193d91ef679173ef211275b9ad457f
810948facab2268139a1d4aac1368282e5ef1a9a
56f321d71b1bf6180977e9e3ff23836350ea2921 020
9e7f5cfb0fa20c44747f3d9111ccf161a2892
6160d0084fb8b02c3c1b5f1dd835d921d53ec86a
84de8b17fcab52a9c00587b81eb043c8614b37c5 68762f
c23396e88e8ef8a1497d4f340a1bd69fa4
96bb86bfdd5f506ef233608c2ca8d58a13c834dd
287c7e907cd41dba25454d5708262e73a80c2bbb 2fcde3a98
09755d33f4b4093b1f2ef319f7ebe36
8e5b9847a38905e9d921d231c712c54720a4de5a
6ecfbc2bde9b771fba56d4b85ad2952b4fe0405c 0b71dc288ac2
af4a2670e608c22e26beee272fd0 455601d6f414e400bfabb6410074b6ebee2696e0
e78e5c0b98dfd44cc9e1e5d56a1e094d295a7c97
First of all, this log's content is next to zero. Secondly, all
reflogs are already empty and I expected no output at all.
--Leo--
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Andreas Ericsson @ 2008-10-30 15:25 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Bill Lear, git
In-Reply-To: <2008-10-30-16-04-08+trackit+sam@rfc1149.net>
Samuel Tardieu wrote:
> * Andreas Ericsson <ae@op5.se> [2008-10-30 15:54:53 +0100]
>
>> Correct me if I'm wrong, but wouldn't my suggestion of not trying to
>> push (even matching) branches that haven't been updated since we last
>> fetched from the remote do exactly the same thing for your particular
>> use-case, but without syntax change and all the annoying minor parts
>> that it entails?
>
> Not exactly. I often do some work on a branch which does not mandate
> a topic branch and have to switch branches to fix a bug for example.
> This would continue to push unterminated changes as well.
>
> Typical use case, which happens (to me) quite frequently:
>
...
>
> Argh, "master" has been pushed as well. Ok, I could have done
>
Ah, I see. I sympathize, although I really do think you'd be
better off by learning to explicitly push things.
> % git branch
> (because I know I am on the right branch but do not necessarily
> remember its full name all the time)
offtopic: Use shell-completion and set your PS1 to include the __git_ps1
output.
> % git push origin 2.0-beta1-release-candidate
>
> or I could have started a topic branch, but I often push 2 or 3
> commits at a time instead, the first one being a refactoring of
> existing code to ease the subsequent one.
>
I fail to see why this would prevent you from starting a topic-branch.
In fact, I would have thought it was a reason *for* starting a topic.
>>From what I have seen, people I am working with often have the
> same workflow (do not systematically start a topic branch when
> in active development mode)
>
>> Define "many". Perhaps as often as 2-3 times per day. Not very often,
>> but frequent enough that I definitely want some short sweet way of
>> doing it. OTOH, I also find the "rejected" messages annoying, and I
>> definitely feel one could do something about them. However, it's my
>> birthday today and I plan on being far too drunk/hungover the entire
>> weekend for me to take any actions in that direction.
>
> Happy birthday :)
>
Thank you :-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Matthieu Moy @ 2008-10-30 15:20 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git
In-Reply-To: <20081030143918.GB14744@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> * Add the command "git revert-file <files>" which is syntactic sugar for:
>
> git checkout HEAD -- <files>
I don't think "revert-file" is a good name for this: although other
SCM often call this "revert", what Git calls "revert" is about
reverting an existing commit (it's "backout" in hg for example). The
terminology to revert the working tree to the last commited version is
already here in Git, it's "reset".
I've already argued in favor of allowing "git reset --hard <files>",
which is consistant with existing terminology and doesn't add an extra
command, but without success.
--
Matthieu
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Bill Lear @ 2008-10-30 15:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Samuel Tardieu, git
In-Reply-To: <4909D1FE.2080403@op5.se>
On Thursday, October 30, 2008 at 16:25:50 (+0100) Andreas Ericsson writes:
>Samuel Tardieu wrote:
>> * Andreas Ericsson <ae@op5.se> [2008-10-30 15:54:53 +0100]
>>
>>> Correct me if I'm wrong, but wouldn't my suggestion of not trying to
>>> push (even matching) branches that haven't been updated since we last
>>> fetched from the remote do exactly the same thing for your particular
>>> use-case, but without syntax change and all the annoying minor parts
>>> that it entails?
>>
>> Not exactly. I often do some work on a branch which does not mandate
>> a topic branch and have to switch branches to fix a bug for example.
>> This would continue to push unterminated changes as well.
>>
>> Typical use case, which happens (to me) quite frequently:
>>
>
>...
>
>>
>> Argh, "master" has been pushed as well. Ok, I could have done
>>
>
>Ah, I see. I sympathize, although I really do think you'd be
>better off by learning to explicitly push things.
Exactly my concerns when I raised this issue originally. It's hard to
teach people to do this:
% git push origin master
or:
% git pull origin master
so that when they intend and MUST do this (lest chaos ensue):
% git push origin ReleaseBranch
or this:
% git pull origin ReleaseBranch
they don't mistakenly do this:
% git push
or:
% git pull
the reason being that every manual our users read says "use git push",
use "git pull", the examples being written for 'master' branch usage,
and people just assume that 'git push'/'git pull' are smart enough to
know which branch you are on and do the same logical thing as a bare
'git push'/'git pull' does when on master.
Several times this has happened to us: people make this mistake and
push or pull stuff into a branch they do not want. The pull is not so
bad, but the push messes up our central repo. This has happened both
here at my current company, and my previous one, and the persons
making the mistakes are neither sloppy nor inexperienced.
Bill
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Julian Phillips @ 2008-10-30 15:25 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030132453.GB24098@artemis.corp>
On Thu, 30 Oct 2008, Pierre Habouzit wrote:
> On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote:
>> +Working with patches
>> +--------------------
>> +
>> + * 'git send-email' should prompt for all SMTP-related information
>> + about sending e-mail when it is running with no configuration.
>> + Because these days /usr/lib/sendmail is rarely configured
>> + correctly.
>
> And when the user answer them, it should set them (a bit like zsh does
> when it's run from the first time e.g.)
>
>> +
>> + * other git send-email functionality which has bitten people -
>> + particularly building the recipient list - should prompt for
>> + confirmation until configured to be automatic.
>> +
>
> * git-send-email should be either more interactive, or less: either
> just use the damn configuration, or propose a mode where it spawns
> an editor for each patch so that you can add further comments.
>
> * git-send-email should be able to format-patches by himself (IOW
> accept most of format-patch arguments and deal with the patch list
> by himself, which is usable if the previous point is implemented).
This gets my vote ...
These are two of the reasons that I ended up ignoring git-send-email and
writing my own replacement. I found the whole format-patch/send-email
dance too cumbersome and confusing - particularly for sending a single
patch. To send a single patch I ended up with the command:
git mail-commmits --edit HEAD~1
It would be nice if I could replace this with:
git send-email --edit HEAD~1
;)
>
>> + * 'git am -3' the default; with global option to make it not the
>> + default for those that prefer the speed of -2
>> +
>> +
--
Julian
---
Blessed be those who initiate lively discussions with the hopelessly mute,
for they shall be know as Dentists.
^ permalink raw reply
* filter-branch enhancements
From: Pierre Habouzit @ 2008-10-30 16:18 UTC (permalink / raw)
To: git; +Cc: pasky, srabbelier
In-Reply-To: <20081030132623.GC24098@artemis.corp>
The first patch is about making git-filter-branch use parse options, and
is independant, but the current state made my eyes bleed, and I wanted
to work on the second patch ;)
The second patch is more a request for comments, and if people think
it's useful, I'll try to check it actually works, and write some tests
for it.
^ permalink raw reply
* [Proof of concept PATCH] implement --prune-empty switch for filter-branch
From: Pierre Habouzit @ 2008-10-30 16:18 UTC (permalink / raw)
To: git; +Cc: pasky, srabbelier, Pierre Habouzit
In-Reply-To: <1225383538-23666-2-git-send-email-madcoder@debian.org>
This is not a real patch (lacks a test at least) and is absolutely not
tested, though should basically work as expected.
This is only meant as a basis for discussion.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-filter-branch.txt | 14 ++++++++++++++
git-filter-branch.sh | 26 +++++++++++++++++++++++++-
2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index fed6de6..451950b 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -122,6 +122,10 @@ You can use the 'map' convenience function in this filter, and other
convenience functions, too. For example, calling 'skip_commit "$@"'
will leave out the current commit (but not its changes! If you want
that, use 'git-rebase' instead).
++
+You can also use the 'git_commit_non_empty_tree "$@"' instead of
+'git commit-tree "$@"' if you don't wish to keep commits with a single parent
+and that makes no change to the tree.
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@@ -151,6 +155,16 @@ to other tags will be rewritten to point to the underlying commit.
The result will contain that directory (and only that) as its
project root.
+--prune-empty::
+ Some kind of filters will generate empty commits, that left the tree
+ untouched. This switch allow git-filter-branch to ignore such
+ commits. Though, this switch only applies for commits that have one
+ and only one parent, it will hence keep merges points. Also, this
+ option is not compatible with the use of '--commit-filter'. Though you
+ just need to use the function 'git_commit_non_empty_tree "$@"' instead
+ of the 'git commit-tree "$@"' idiom in your commit filter to make that
+ happen.
+
--original <namespace>::
Use this option to set the namespace where the original commits
will be stored. The default value is 'refs/original'.
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 8af3126..9c83402 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -49,6 +49,15 @@ die()
echo "$*" >&2
exit 1
}
+
+git_commit_non_empty_tree()
+{
+ if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
+ map "$3"
+ else
+ git commit-tree "$@"
+ fi
+}
EOF
)
@@ -95,6 +104,7 @@ d= temporary path to use for rewriting
f,force force filter-branch to run
subdirectory-filter= only look at the history touching that specific subdirectory
original= namespace where the original commits will be stored (default: refs/original)
+prune-empty use this if you want to automatically prune empty commits
Filters that you can run:
@@ -121,11 +131,12 @@ filter_tree=
filter_index=
filter_parent=
filter_msg=cat
-filter_commit='git commit-tree "$@"'
+filter_commit=
filter_tag_name=
filter_subdir=
orig_namespace=refs/original/
force=
+prune_empty=
while :
do
case "$1" in
@@ -138,6 +149,8 @@ do
--original)
orig_namespace=$(expr "$2/" : '\(.*[^/]\)/*$')/
shift;;
+ --prune-empty)
+ prune_empty=t;;
--env-filter)
filter_env="$2"; shift;;
@@ -161,6 +174,17 @@ do
shift
done
+case "$prune_empty,$filter_commit" in
+',')
+ filter_commit='git commit-tree "$@"';;
+'t,')
+ filter_commit='git_commit_non_empty_tree "$@"';;
+','*)
+ ;;
+*)
+ die "Cannot set --prune-empty and --filter-commit at the same time"
+esac
+
case "$force" in
t)
rm -rf "$tempdir"
--
1.6.0.3.758.gc29b0
^ 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