* Re: kha/safe and kha/experimental updated
From: Jakub Narebski @ 2007-12-19 10:44 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, David Kågedal, git
In-Reply-To: <20071219093816.GB4361@diana.vm.bytemark.co.uk>
On Wed, 19 Dec 2007, Karl Hasselström wrote:
> On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> > "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> >
> > > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> > >
> > > > Remove "stg resolved"
> > >
> > > I'd like to keep this command. git-mergetool doesn't support the
> > > tool I use (emacs + ediff and more stgit-specific file extensions
> > > like current, patch etc.). I also don't find 'git add' to be
> > > meaningful for marking a conflict as solved.
> >
> > I also would like to have this command kept (and shown in 'stg
> > help'!). Contrary to 'git add' it can check and add to index /
> > update index only for files with conflict; we have -r
> > (ancestor|current|patched) to choose one side, and we could add
> > --check to check if there are no conflict markers with files (useful
> > with -a/--all).
>
> This too sounds like stuff that could profitably be added to "git
> add". Except for the ancestor/current/patched words, it is not
> specific to patch stacks, so the implementation should be in git and
> not in stg.
No it cannot, at least the '-r (ancestor|current|patched)' part for
resetting file to given version, even if we change the wording to
ancestor, ours and theirs. The git-add command is about adding contents,
which updates index, which almost as a intended side-effect clears
merge state, i.e. stages; and not about resetting to stage.
Besides with "stg resolved" you can update index _only_ for files
which were in the conflict, also for -a/--all, and not all the files
not only those which were in the conflict like "git add -u" does.
"stg resolved --check" could happily ignore things that only look
like conflict markers, but must have been intended, because they are
in files not in conflict.
Unless you are talking about adding "resolve"/"resolved" command
to git-core, as a porcelain wrapper around git-update-index, like
"git add"...
P.S. I have just noticed that 'git-checkout' [<tree-ish>] <paths>...
form of operation is not documented; you can derive what it do
only from examples.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 10:19 UTC (permalink / raw)
To: David Kågedal; +Cc: Jakub Narebski, git, Karl Hasselström
In-Reply-To: <87bq8nkoma.fsf@lysator.liu.se>
On 19/12/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> > I'd also like to re-add the stgit.keeporig option and additional
> > functionality so that the *.{ancestor,current,patched} can be left in
> > the working tree. Some people might use them when manually fixing
> > conflicts (I have a look at them from time to time when the emacs +
> > ediff shows a hard to understand conflict).
>
> Since all the information is in git, it is of course easy to recreate
> it. But the important question to ask is: how do you use these extra
> files? git.el provides a way to diff against both parent versions, and
> maybe that is actually what you need.
>
> I don't mind that you want these files, but they are mostly clutter to
> me.
You can set stgit.keeporig to 'no' if you don't want these files.
For people not using emacs + git.el, the files might be useful. As you
said, you could use 'git diff -2/-3' but, in various occasions I just
wanted to copy a block of code from one of the checked-out stages.
Without this feature, I would have to use plain git and remember what
stage corresponds to my patch.
Note that there are other users (apart from me) that use StGIT almost
exclusively. I really don't like forcing them to use more and more
plain git commands (at some point, they might even discover 'git
rebase -i' to be good enough and give up on StGIT :-)).
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 10:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071219093400.GA4361@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-18 16:09:24 +0000, Catalin Marinas wrote:
>
> > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > "stg status --reset" is not needed anymore
> >
> > I would keep this as an alias for 'git reset --hard' (see below as
> > well).
> >
> > > Remove "stg add"
> > > Remove "stg rm"
> > > Remove "stg cp"
> >
> > I plan to add a generic command for these kind of aliases. The
> > reason is that I don't really like mixing GIT and StGIT commands (I
> > think at some point I'll get confused and try to run stg commands
> > with git).
>
> How should these aliases be presented in the documentation etc.? I
> suggest making it very clear that they are only aliases.
Yes, 'stg help' should clearly mark them as aliases of git commands.
I'm not sure how I'll do this yet. For the 'status --reset', I'll keep
it if we have a separate 'resolved' command.
> > > Remove "stg resolved"
> >
> > I'd like to keep this command. git-mergetool doesn't support the
> > tool I use (emacs + ediff and more stgit-specific file extensions
> > like current, patch etc.).
>
> So why have a separate command instead of fixing git-mergetool?
In the past, StGIT only used the core git functionality and stayed
away from the porcelain scripts. We now started to use some of the
built-in commands more and more and I think it is fine but the git
scripts look more volatile to me than the C code (look at the many
variants the git merging went through, from shell scripts to python
and only now seems to be stabilised with the recursive merge as a
built-in command).
Adding the functionality I need to git-mergetool would also mean
always using the latest GIT with StGIT. Anyway, if you like
git-mergetool, I think you can easily change the StGIT configuration
to
> > I also don't find 'git add' to be meaningful for marking a conflict
> > as solved.
>
> So maybe let "stg resolved" be an alias for "git add"?
It's not a simple alias, if you use 'stg resolved -a'. Now, if we
allow stgit.keeporig, it needs even more functionality.
> This is all our usual disagreement: You want stg to be a fairly
> standalone tool, and I want it to be a tool to use side by side with
> git. The problem I see with your approach is that stg risks ending up
> like Cogito: it'll provide inspiration for improving git, but will
> itself become obsolete because of the simple fact that git has so much
> more development manpower.
If GIT would have all the functionality I need for my workflow, I
wouldn't mind giving up StGIT (I started StGIT because I needed easier
patch management on top of GIT and modifying Quilt would've been too
intrusive).
> I think it'd be more productive to let stg
> do one thing -- patch stacks -- and do it well, and rely on git for
> everything else.
In principle, yes, but I have some minor problems with the UI of GIT
(like resolved == add). I think there is also a fundamental difference
between 'git commit' and 'stg refresh'. The former requires explicit
marking of the files to commit (or use the -a option) while the latter
always adds all the local changes to the current patch. Maybe GIT
users are more used to running 'git add' after fixing a conflict but I
use StGIT almost exclusively.
> Of course, if stuff like "stg add" and "stg resolved" are really
> implemented as three-line wrappers around git commands, we don't have
> that problem.
For add/rm/cp, they should just be a generic wrapper which doesn't
even parse the command line options. That's not the case with
'resolved'.
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: David Kågedal @ 2007-12-19 9:50 UTC (permalink / raw)
To: Catalin Marinas, Jakub Narebski; +Cc: Karl Hasselström, git
In-Reply-To: <87bq8nkoma.fsf@lysator.liu.se>
David Kågedal <davidk@lysator.liu.se> writes:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>
>> On 18/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>>> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>>>
>>> > Thanks again for maintaining these branches.
>>> >
>>> > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>>> > > git://repo.or.cz/stgit/kha.git safe
>>>
>>> > > Remove "stg resolved"
>>> >
>>> > I'd like to keep this command. git-mergetool doesn't support the tool
>>> > I use (emacs + ediff and more stgit-specific file extensions like
>>> > current, patch etc.). I also don't find 'git add' to be meaningful for
>>> > marking a conflict as solved.
>>>
>>> I also would like to have this command kept (and shown in 'stg help'!).
>>> Contrary to 'git add' it can check and add to index / update index
>>> only for files with conflict; we have -r (ancestor|current|patched)
>>> to choose one side, and we could add --check to check if there are
>>> no conflict markers with files (useful with -a/--all).
>>
>> I'd also like to re-add the stgit.keeporig option and additional
>> functionality so that the *.{ancestor,current,patched} can be left in
>> the working tree. Some people might use them when manually fixing
>> conflicts (I have a look at them from time to time when the emacs +
>> ediff shows a hard to understand conflict).
>
> Since all the information is in git, it is of course easy to recreate
> it. But the important question to ask is: how do you use these extra
> files? git.el provides a way to diff against both parent versions, and
> maybe that is actually what you need.
Note that I'm talking about the kha/experimental branch here. The
point of my patches there are to make sure that the git index is left
in the unmerged state so that normal git tools can be used. This
means that git diff-files -2 and -3 does what you want.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] clone: fix options '-o' and '--origin' to be recognised again
From: Junio C Hamano @ 2007-12-19 9:45 UTC (permalink / raw)
To: Marco Roeland; +Cc: git, Pierre Habouzit, Kristian Høgsberg
In-Reply-To: <20071219091515.GA20707@fiberbit.xs4all.nl>
Thanks. That indeed was embarrassing.
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: David Kågedal @ 2007-12-19 9:41 UTC (permalink / raw)
To: Jakub Narebski, Catalin Marinas; +Cc: git, Karl Hasselström
In-Reply-To: <b0943d9e0712180852y62c5bea2x61463b235b26ca04@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 18/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>>
>> > Thanks again for maintaining these branches.
>> >
>> > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>> > > git://repo.or.cz/stgit/kha.git safe
>>
>> > > Remove "stg resolved"
>> >
>> > I'd like to keep this command. git-mergetool doesn't support the tool
>> > I use (emacs + ediff and more stgit-specific file extensions like
>> > current, patch etc.). I also don't find 'git add' to be meaningful for
>> > marking a conflict as solved.
>>
>> I also would like to have this command kept (and shown in 'stg help'!).
>> Contrary to 'git add' it can check and add to index / update index
>> only for files with conflict; we have -r (ancestor|current|patched)
>> to choose one side, and we could add --check to check if there are
>> no conflict markers with files (useful with -a/--all).
>
> I'd also like to re-add the stgit.keeporig option and additional
> functionality so that the *.{ancestor,current,patched} can be left in
> the working tree. Some people might use them when manually fixing
> conflicts (I have a look at them from time to time when the emacs +
> ediff shows a hard to understand conflict).
Since all the information is in git, it is of course easy to recreate
it. But the important question to ask is: how do you use these extra
files? git.el provides a way to diff against both parent versions, and
maybe that is actually what you need.
I don't mind that you want these files, but they are mostly clutter to
me.
--
David Kågedal
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 9:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Catalin Marinas, David Kågedal, git
In-Reply-To: <m3hcigot3h.fsf@roke.D-201>
On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>
> > On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > Remove "stg resolved"
> >
> > I'd like to keep this command. git-mergetool doesn't support the
> > tool I use (emacs + ediff and more stgit-specific file extensions
> > like current, patch etc.). I also don't find 'git add' to be
> > meaningful for marking a conflict as solved.
>
> I also would like to have this command kept (and shown in 'stg
> help'!). Contrary to 'git add' it can check and add to index /
> update index only for files with conflict; we have -r
> (ancestor|current|patched) to choose one side, and we could add
> --check to check if there are no conflict markers with files (useful
> with -a/--all).
This too sounds like stuff that could profitably be added to "git
add". Except for the ancestor/current/patched words, it is not
specific to patch stacks, so the implementation should be in git and
not in stg.
IMHO, of course. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-svn fix for broken symlinks
From: Junio C Hamano @ 2007-12-19 9:37 UTC (permalink / raw)
To: Eric Wong; +Cc: Sverre Johansen, git
In-Reply-To: <20071219084853.GB17787@muzzle>
Thanks. I was about to ask you about some patches I saw on the list
from you.
Pulled; will push out tomorrow.
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 9:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712180809l4d2d01b8j32ab2a410885cc5e@mail.gmail.com>
On 2007-12-18 16:09:24 +0000, Catalin Marinas wrote:
> On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > "stg status --reset" is not needed anymore
>
> I would keep this as an alias for 'git reset --hard' (see below as
> well).
>
> > Remove "stg add"
> > Remove "stg rm"
> > Remove "stg cp"
>
> I plan to add a generic command for these kind of aliases. The
> reason is that I don't really like mixing GIT and StGIT commands (I
> think at some point I'll get confused and try to run stg commands
> with git).
How should these aliases be presented in the documentation etc.? I
suggest making it very clear that they are only aliases.
> > Remove "stg resolved"
>
> I'd like to keep this command. git-mergetool doesn't support the
> tool I use (emacs + ediff and more stgit-specific file extensions
> like current, patch etc.).
So why have a separate command instead of fixing git-mergetool?
> I also don't find 'git add' to be meaningful for marking a conflict
> as solved.
So maybe let "stg resolved" be an alias for "git add"?
This is all our usual disagreement: You want stg to be a fairly
standalone tool, and I want it to be a tool to use side by side with
git. The problem I see with your approach is that stg risks ending up
like Cogito: it'll provide inspiration for improving git, but will
itself become obsolete because of the simple fact that git has so much
more development manpower. I think it'd be more productive to let stg
do one thing -- patch stacks -- and do it well, and rely on git for
everything else.
Of course, if stuff like "stg add" and "stg resolved" are really
implemented as three-line wrappers around git commands, we don't have
that problem.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] clone: fix options '-o' and '--origin' to be recognised again
From: Marco Roeland @ 2007-12-19 9:15 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Pierre Habouzit, Kristian Høgsberg
Due to a subtle typo in a shell case pattern neither alternative worked.
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
---
This is a regression in 'next', introduced on Nov 4th by commit 94362599
"Migrate git-clone to use git-rev-parse --parseopt". Added Kristian as
he works on the builtin version; perhaps nice for a test case (!).
git-clone.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 9a160ee..b4e858c 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -152,7 +152,7 @@ do
die "clones are always made with separate-remote layout" ;;
--reference)
shift; reference="$1" ;;
- -o,--origin)
+ -o|--origin)
shift;
case "$1" in
'')
--
1.5.4.rc0.1162.g3bfea
^ permalink raw reply related
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Johannes Sixt @ 2007-12-19 9:21 UTC (permalink / raw)
To: Andreas Ericsson, Pascal Obry; +Cc: Pascal Obry, git
In-Reply-To: <4768DC78.9010304@op5.se>
Andreas Ericsson schrieb:
> Pascal Obry wrote:
>> Andreas Ericsson a écrit :
>>> Pascal Obry wrote:
>>>> int thread = 0;
>>>> + int no_name_prefix = 0;
>>> Do we not need no double negations, yes?
>>
>> Not sure, looks clearer to use variable name corresponding to the option
>> name to me...
Sure. Only that the option name is --name-prefix, and the no- part of it
is just the negation (that many other long option names also offer).
> Perhaps. We just had this discussion on the list where multiple people had
> extended a negative-sounding option. Personally I find it hard to parse
> and bug-prone to write (and edit) something like
>
> if (!no_prefix)
> add_the_prefix();",
>
> but perhaps that's just me.
Oh, no, you are not alone!
Johannes "We-don't-need-no-steenkin'-duuble-negations" Sixt
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-19 9:13 UTC (permalink / raw)
To: Gerald Gutierrez
Cc: 'Junio C Hamano', 'Johannes Schindelin', git
In-Reply-To: <000d01c841c5$386f7350$762a14ac@na.acco.com>
"Gerald Gutierrez" <ggmlfs@gmail.com> writes:
> if (user_redefined_changed)
> if (user_defn_of_changed(work, head)) commit(work);
> else
> if (builtin_changed(work, head)) commit(work);
That would lead to even less intuitive semantics.
Suppose your working tree has two changes, like
--- a/file
+++ b/file
@@ ... @@
-old ignored line
+new ignored line
@@ ... @@
-this is relevant
+change
What would git be supposed to do if you ignore anything containing
"ignored"?
If git commits, it will commit both changes. People checking-out the
new revision will get "new ignored line" in the file. So, a portion of
the diff that you wanted to ignore has actually gone into the
repository. IOW, whether "new ignored line" would go into the
repository depends on the presence of another unrelated change.
Perhaps you would have expected this, but I wouldn't, and I bet many
other users wouldn't either. And usually, when you can't have people
agree on a common reasonable semantics, the answer is "don't put it in
git, let people script the semantics they want".
Take another example : I use an external diff tool to work with
OpenDocument files. It converts them into text, and calls "git diff"
on them. My diff driver therefore ignores formatting changes. If I
made only content changes, I get no change with this diff driver.
Still, if I commit, I expect git to record my new formatting.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] git show <tag>: show the tagger
From: Andreas Ericsson @ 2007-12-19 9:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0712181800250.23902@racer.site>
Johannes Schindelin wrote:
> For commit objects, the Author is shown, so do the equivalent for
> tag objects, too.
>
That's funny. I tried to apply this onto my "patches" branch and got
conflicts. I have a near-identical one there that I forgot about
~6 months back, so
Acked-by: Andreas Ericsson <ae@op5.se>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-19 9:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerald Gutierrez, 'Junio C Hamano', git
In-Reply-To: <Pine.LNX.4.64.0712182246230.23902@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Here's what the git-commit manpage on kernel.org says: "git-commit -
>> Record changes to the repository".
>
> Yes. Changes, as in "take this _file_ instead". Not "edit this file,
> remove those lines, add these here, etc.".
That said, I think the wording of the man page could be better.
Perhaps "Record new snapshot to the repository" or "Record current
state of the working tree to the repository".
I can't find something wich is both accurate and newbie friendly ...
("accurate" would probably be "Record index content into the
repository")
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Add format-patch option --no-name-prefix.
From: Andreas Ericsson @ 2007-12-19 8:55 UTC (permalink / raw)
To: Pascal Obry; +Cc: Pascal Obry, git
In-Reply-To: <4767F145.3030109@obry.net>
Pascal Obry wrote:
> Andreas Ericsson a écrit :
>> Pascal Obry wrote:
>>> int thread = 0;
>>> + int no_name_prefix = 0;
>> Do we not need no double negations, yes?
>
> Not sure, looks clearer to use variable name corresponding to the option
> name to me...
>
Perhaps. We just had this discussion on the list where multiple people had
extended a negative-sounding option. Personally I find it hard to parse
and bug-prone to write (and edit) something like
if (!no_prefix)
add_the_prefix();",
but perhaps that's just me.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-svn fix for broken symlinks
From: Eric Wong @ 2007-12-19 8:48 UTC (permalink / raw)
To: Junio C Hamano, Sverre Johansen; +Cc: git
In-Reply-To: <a74c0d680712180811m216699a4h7123039c3158c2ed@mail.gmail.com>
Sverre Johansen <sverre.johansen@gmail.com> wrote:
> Hi,
>
> There is a bug in older versions of SVN that makes it possible to create
> symlinks where the target is not the path to the file, but instead the
> content of the target file. The bug is described here [0].
>
> This breaks git-svn because it expects files which is marked as symlinks
> to have the content "link: <filename>".
>
> There was a thread about this back in July, resulting in this patch [1]. Is that
> patch planned to be merged anytime soon? I'm using it, and it works great
> for me.
>
> [0]: http://subversion.tigris.org/issues/show_bug.cgi?id=2692
> [1]: http://kerneltrap.org/mailarchive/git/2007/7/19/252025
Sverre: Thanks for the reminder, I'm quite absent-minded :/
I've pushed out the patch to http://git.bogomips.org/git-svn.git
(or git://, if you prefer) along with two others
Junio: please pull, thanks.
commit 540424b263d626aa762757a31ca9b4becc7fb513
Author: Eric Wong <normalperson@yhbt.net>
Date: Wed Dec 19 00:31:43 2007 -0800
git-svn: avoid warning when run without arguments
While we're in the area, finish writing a halfway-written
comment describing what that block does...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
commit 7fc35e0e94782bbbefb920875813519038659930
Author: Eric Wong <normalperson@yhbt.net>
Date: Wed Dec 19 00:06:45 2007 -0800
git-svn: workaround a for broken symlinks in SVN
It's possible for bad clients to commit symlinks without the
5-character "link " prefix in symlinks. So guard around this
bug in SVN and make a best effort to create symlinks if the
"link " prefix is missing.
More information on this SVN bug is described here:
http://subversion.tigris.org/issues/show_bug.cgi?id=2692
To be pedantic, there is still a corner case that neither we nor
SVN can handle: If somebody made a link using a broken SVN
client where "link " is the first part of its path, e.g.
"link sausage", then we'd end up having a symlink which points
to "sausage" because we incorrectly stripped the "link ".
Hopefully this hasn't happened in practice, but if it has,
it's not our fault SVN is broken :)
Thanks to Benoit Sigoure and Sverre Johansen for reporting
and feedback.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
commit ad94802a7bc599ade73ec0b04c61b2f80b3c1b23
Author: Eric Wong <normalperson@yhbt.net>
Date: Sat Dec 15 19:08:22 2007 -0800
git-svn: avoid leaving leftover committer/author info in rebase
We set the 6 environment variables for controlling
committer/author email/name/time for every commit.
We do this in the parent process to be passed to
git-commit-tree, because open3() doesn't afford us the control
of doing it only in the child process. This means we leave them
hanging around in the main process until the next revision comes
around and all 6 environment variables are overwridden again.
Unfortunately, for the last commit, leaving them hanging around
means the git-rebase invocation will pick it up, rewriting the
rebased commit with incorrect author information. This should fix
it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
--
Eric Wong
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Andreas Ericsson @ 2007-12-19 8:29 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Wincent Colaiuta, Git Mailing List
In-Reply-To: <46a038f90712182346t5309448egebfd3726f4d493c5@mail.gmail.com>
Martin Langhoff wrote:
> On Dec 19, 2007 8:33 PM, Wincent Colaiuta <win@wincent.com> wrote:
>> El 19/12/2007, a las 0:41, Martin Langhoff escribió:
>>
>>> On Dec 19, 2007 4:42 AM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
>>>> I vote for stash print the list, because I dropped in the pitfall.
>>> I've dropped there myself, and work with a large team where we are
>>> both fans of stash, and scarred by it. Any newcomer to git that
>>> "discovers" stash gets hit by it a dozen times, this is completely
>>> unnecesary.
>> I may be missing something here, but what's the danger here? An
>
> Surprise. Your working directory has *just* changed under your feet.
> Maybe you have an editor with further unsaved changes that is about to
> act confused whether you undo the stash or not.
>
>> unexpected stash is incredibly easy to revert, unless I'm missing
>
> Once you know about it, yes it is. Once you know about the reflog, you
> can sing and dance and never be worried. But for starting users, it's
> a dangerous command.
>
>> And nobody commented on the idea I posted earlier which
>> seems to address the concerns about newbies not knowing what "git
>> stash" with no params does:
>
> I agree with making stash more verbose -- if the unlucky new user is
> paying close attention, they'll have instructions on to how to get out
> of trouble. But I agree more with making it "just verbose, no action"
> by default. There are two strong hints:
>
> - all other state-changing commands take parameters
> - quite a few people in this list have gotten burned with it
>
> Even after knowing pretty well how stash works, I still get mixed up
> sometimes with the 'clear/clean/list' stuff. Or have a typo in the
> command.
>
The clear vs clean confusion has been remedied though, and you can no
longer create a named stash without using "git stash save" with a
recent enough version of git.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Problem with git-svn
From: Eric Wong @ 2007-12-19 8:27 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <4764FE2C.1010103@obry.net>
Pascal Obry <pascal@obry.net> wrote:
>
> I'm trying to use a Subversion repository with Git. I had
> great success with many repositories except one. This one
> live since long time and as been migrated from CVS to
> Subversion.
>
> The current Subversion repository contains multiple projects.
> Each project is under /trunk. While trying to import the project
> PROJ:
>
> $ git svn clone svn+ssh://myserver/trunk/PROJ
>
> I get:
>
> Initialized empty Git repository in .git/
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'
> Found possible branch point: svn+ssh://myserver/importfromcvs/trunk =>
> svn+ssh://myserver/trunk/PROJ, 48467
> Initializing parent: git-svn@48467
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: File not found: revision 101, path
> '/importfromcvs/trunk'
> r9458 = b90789186c85a19a9f32ea6dc8a4259e2eadef67 (git-svn@48467)
> A file.el
>
> But file.el is not part of this project, it is part of another one
> on the same Subversion repository. It looks like git-svn get confused
> at some point. I've been trying to track this down, but since I've
> never written a single Perl script that's not easy :(
Hi,
Can you show me the output of `svn log -v -r9458 svn+ssh://myserver/' ?
Thanks.
> Note that AFAIK each CVS modules have been imported into
> /importfromcvs/trunk then move into /trunk/<MODULE_NAME>.
>
> r48467 seem ok as a branch point:
>
> <<
> ------------------------------------------------------------------------
> r48468 | svn | 2007-05-09 15:10:54 +0200 (Wed, 09 May 2007) | 1 line
> Changed paths:
> D /importfromcvs/trunk
> A /trunk/PROJ (from /importfromcvs/trunk:48467)
>
> Importing module PROJ into SVN.
> >>
So did svn+ssh://importfromcvs/trunk/file.el at r9458? If so, git-svn
is behaving as expected. If not, can you tell me where "file.el" was at
r9458?
>
> So I'm looking for hints about the possible problem.
>
> Note that I have tried to reproduce this with a small
> script (using the same repository structure) but I was
> not able.
--
Eric Wong
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Martin Langhoff @ 2007-12-19 7:46 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <38C1471E-0927-4B43-AF73-70735820F8F9@wincent.com>
On Dec 19, 2007 8:33 PM, Wincent Colaiuta <win@wincent.com> wrote:
> El 19/12/2007, a las 0:41, Martin Langhoff escribió:
>
> > On Dec 19, 2007 4:42 AM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
> >> I vote for stash print the list, because I dropped in the pitfall.
> >
> > I've dropped there myself, and work with a large team where we are
> > both fans of stash, and scarred by it. Any newcomer to git that
> > "discovers" stash gets hit by it a dozen times, this is completely
> > unnecesary.
>
> I may be missing something here, but what's the danger here? An
Surprise. Your working directory has *just* changed under your feet.
Maybe you have an editor with further unsaved changes that is about to
act confused whether you undo the stash or not.
> unexpected stash is incredibly easy to revert, unless I'm missing
Once you know about it, yes it is. Once you know about the reflog, you
can sing and dance and never be worried. But for starting users, it's
a dangerous command.
> And nobody commented on the idea I posted earlier which
> seems to address the concerns about newbies not knowing what "git
> stash" with no params does:
I agree with making stash more verbose -- if the unlucky new user is
paying close attention, they'll have instructions on to how to get out
of trouble. But I agree more with making it "just verbose, no action"
by default. There are two strong hints:
- all other state-changing commands take parameters
- quite a few people in this list have gotten burned with it
Even after knowing pretty well how stash works, I still get mixed up
sometimes with the 'clear/clean/list' stuff. Or have a typo in the
command.
cheers,
martin
^ permalink raw reply
* Re: [BUG] Invalid rebase command leaves unclean status
From: Wincent Colaiuta @ 2007-12-19 7:42 UTC (permalink / raw)
To: ulrik; +Cc: git
In-Reply-To: <a1b6cb1b0712181647v34822692t4a3d88f90cd7346@mail.gmail.com>
El 19/12/2007, a las 1:47, ulrik escribió:
> Hello git list
>
> A bug in rebase -i: A typo in the command (for example in the branch
> name) still makes later invocations of rebase think a rebase is
> already in process.
It's already been fixed on master:
$ mkdir demo
$ git init
Initialized empty Git repository in .git/
$ echo a > a
$ git add a
$ git commit -m a
Created initial commit 36a2b58: a
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
$ git checkout -b other
Switched to a new branch "other"
$ git rebase -i muster
fatal: Needed a single revision
Invalid base
$ git rebase -i master
Nothing to do
Cheers,
Wincent
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Alex Riesen @ 2007-12-19 7:42 UTC (permalink / raw)
To: Dana How; +Cc: Linus Torvalds, Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com>
Dana How, Wed, Dec 19, 2007 02:52:23 +0100:
> Given that the root of the current working tree, the commit, the cwd,
> and the path (suffix) given on the command line are all known precisely,
> it does not seem dangerous to come up with an exact rule to combine them
> which is only triggered by some specific syntax.
>
> This does not need to work in bare repositories.
>
And it wont in both patches (your and mine): they don't have prefix
(aka cwd) at all. The bare repos are just no problem, the pathnames
there are always project-absolute.
^ permalink raw reply
* Re: [PATCH] Simple support for tree entry specification with relative pathnames
From: Alex Riesen @ 2007-12-19 7:36 UTC (permalink / raw)
To: Dana How; +Cc: git
In-Reply-To: <56b7f5510712181539g27bd4fc9y632ebe74d91b8e82@mail.gmail.com>
Dana How, Wed, Dec 19, 2007 00:39:13 +0100:
> So has this idea been shut down again?
So it seems. Definitely not for 1.5.*
> I don't have the time to update my May 4 patch right now,
> but you are welcome to look at it and see if it has anything useful.
It is very similar.
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Wincent Colaiuta @ 2007-12-19 7:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90712181541x781c3ebcq6d85b88dbf5cbe23@mail.gmail.com>
El 19/12/2007, a las 0:41, Martin Langhoff escribió:
> On Dec 19, 2007 4:42 AM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
>> I vote for stash print the list, because I dropped in the pitfall.
>
> I've dropped there myself, and work with a large team where we are
> both fans of stash, and scarred by it. Any newcomer to git that
> "discovers" stash gets hit by it a dozen times, this is completely
> unnecesary.
I may be missing something here, but what's the danger here? An
unexpected stash is incredibly easy to revert, unless I'm missing
something. And nobody commented on the idea I posted earlier which
seems to address the concerns about newbies not knowing what "git
stash" with no params does:
http://marc.info/?l=git&m=119799257404542&w=2
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH 2/2] Catch and handle git-commit failures in git-rebase --interactive
From: Junio C Hamano @ 2007-12-19 7:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20071219064500.GB8915@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Comments welcome. This is on top of my 1/2 patch but we could
> drop my 1/2 and rewrite this to not use --no-verify, but handle
> the git-commit error correctly.
>
> However that would force users to fix whitespace errors in later
> patches in a series if they use -i, even though non-i wouldn't
> require that sort of fix-up. So I think we should do both patches
> in the series.
I agree with both patches.
When one wants to use rebase to fix-up whitespace breakage in patches in
bulk, you can set apply.whitespace to "fix". One bad side effect of
this is that if you usually have apply.whitespace set to "fix" (because
you need to accept a lot of patches but your contributers tend to give
crappy patches), you need to temporarily change the configuration while
rebasing if you do not want to preserve intentional whitespace breakages
(e.g. ones in test scripts). This can be argued either a feature or a
misfeature.
But rebase -i breaking and squashing upon commit failure (including
pre-commit safety) cannot be called either feature nor misfeature --- it
is an outright bug.
^ permalink raw reply
* [PATCH 2/2] Catch and handle git-commit failures in git-rebase --interactive
From: Shawn O. Pearce @ 2007-12-19 6:45 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
If git-commit fails for any reason then git-rebase needs to stop
and not plow through the rest of the series. Its unlikely that
a future git-commit will succeed if the current attempt failed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Comments welcome. This is on top of my 1/2 patch but we could
drop my 1/2 and rewrite this to not use --no-verify, but handle
the git-commit error correctly.
However that would force users to fix whitespace errors in later
patches in a series if they use -i, even though non-i wouldn't
require that sort of fix-up. So I think we should do both patches
in the series.
This has also bitten me a few times. :-\
git-rebase--interactive.sh | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index b846ea8..0f7d939 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -289,22 +289,22 @@ do_next () {
output git reset --soft HEAD^
pick_one -n $sha1 || failed=t
echo "$author_script" > "$DOTEST"/author-script
- case $failed in
- f)
+ if test $failed = f
+ then
# This is like --amend, but with a different message
eval "$author_script"
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
- $USE_OUTPUT git commit --no-verify -F "$MSG" $EDIT_COMMIT
- ;;
- t)
+ $USE_OUTPUT git commit --no-verify -F "$MSG" $EDIT_COMMIT || failed=t
+ fi
+ if test $failed = t
+ then
cp "$MSG" "$GIT_DIR"/MERGE_MSG
warn
warn "Could not apply $sha1... $rest"
die_with_patch $sha1 ""
- ;;
- esac
+ fi
;;
*)
warn "Unknown command: $command $sha1 $rest"
@@ -372,7 +372,8 @@ do
test ! -f "$DOTEST"/amend || git reset --soft HEAD^
} &&
export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
- git commit --no-verify -F "$DOTEST"/message -e
+ git commit --no-verify -F "$DOTEST"/message -e ||
+ die "Could not commit staged changes."
require_clean_work_tree
do_rest
--
1.5.4.rc0.1155.g12ed9
^ 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