* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Martin Langhoff @ 2007-12-18 23:31 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sergei Organov, Andreas Ericsson, Jakub Narebski, Sebastian Harl,
Junio C Hamano, Benoit Sigoure, git
In-Reply-To: <Pine.LNX.4.64.0712181803070.23902@racer.site>
On Dec 19, 2007 7:03 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Sorry, I have no time for this kind of discussions.
Johannes,
the way you normally "say" that is by not replying. Please help keep
things civil.
cheers,
martin
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: André Goddard Rosa @ 2007-12-18 23:32 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git
In-Reply-To: <20071218154211.GB12549@alea.gnuu.de>
On Dec 18, 2007 1:42 PM, Jörg Sommer <joerg@alea.gnuu.de> wrote:
> Hi,
>
> Junio C Hamano schrieb am Mon 17. Dec, 16:31 (-0800):
> > Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> >
> > >> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> > >>
> > >>> ... The current behavior of git stash is very
> > >>> dangerous ...
> > > ...
> > >> This is a plain FUD, isn't it? The first Oops should not happen these
> > >> days.
> >
> > But the original point by Sebastian hasn't been answered. He wanted to
> > make the command list the stash without arguments.
> >
> > This was discussed already in the early days of stash and there indeed
> > was a suggestion to do so (I think I sided with that), but the users did
> > not want it. IIRC, the argument went like: "when I say 'stash', that is
> > because I want a quick and immediate way to stash, and I do not want a
> > list. If I do not have to have a quick way, I would create a temporary
> > commit on the current branch, or switch to a temporary branch and commit
> > there."
>
> When it should go quick why don't use an alias. git stash can print the
> list and everyone who wants a quick stash can create an alias for this.
>
> I vote for stash print the list, because I dropped in the pitfall.
>
I got caught by this default too. One vote more!
Regards,
--
[]s,
André Goddard
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Martin Langhoff @ 2007-12-18 23:41 UTC (permalink / raw)
To: Jörg Sommer; +Cc: git
In-Reply-To: <20071218154211.GB12549@alea.gnuu.de>
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.
All state-changing commands need parameters or are interactive (as
it's the case with git-commit). That Johannes & early adopters,
including me, have gotten used to the unintuitive (and dangerously
surprising) behaviour of stash is no excuse to inflict it upon actual
end users. It's way too early for git and the stash command to stick
to a misfeature in the name of backwards compat. We'll adapt, as we
have in the past, to an evolving ui.
And if -- in a new repo -- the list is empty, we can just say so:
Nothing has been stashed yet. Which looks completely different from a
successful stash 'save' command.
cheers,
m
^ permalink raw reply
* Re: git with custom diff for commits
From: Martin Langhoff @ 2007-12-18 23:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerald Gutierrez, Matthieu Moy, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0712182246230.23902@racer.site>
On Dec 19, 2007 11:48 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Yes. Changes, as in "take this _file_ instead". Not "edit this file,
> remove those lines, add these here, etc.".
Exactly. GIT is a "content tracker" that doesn't care about any
semantic meaning in your files. Here's the file, git will store it, as
is. No conversions, not fancy interpretations. Strict, safe and fast.
(There's a small exception there for DOS-style newlines, which was
much resisted.)
You can add external machinery that is aware of your content semantics
-- as you've done with calling GNU diff with ignore patterns to decide
whether to commit or not. But when you tell GIT to commit something,
there's no guessing or transformation involved.
A lot of what GIT achieves is based on that founding principle. Remove
it, and we're toast. For starters, the internal machinery is based on
SHA1 digests that change if you flip a single byte. That's what makes
git fast and realiable. It's not merely an end-user thing.
cheers,
m
^ permalink raw reply
* [BUG] Invalid rebase command leaves unclean status
From: ulrik @ 2007-12-19 0:47 UTC (permalink / raw)
To: git
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.
I found this bug in master, and it was already reported to the mailing
list under version 1.5.3.5, but there were no follow-ups to that mail.
I'm using 1.5.3.7 and it is still present, and looking at the maint
branch it does not seem to be mentioned in post-x.3.7 changes there.
So I am now reporting this bug again. I'm sorry for not checking this
in master, I'll have to ask someone on the list to do that.
Original email:
http://marc.info/?l=git&m=119410951019002&w=2
Date: 2007-11-03 17:04:51
Message-ID: 200711031804.52259.elendil () planet ! nl
# A sample session:
# Invoking rebase with a typo, there is no "muster" branch
$ git rebase -i muster
fatal: Needed a single revision
Invalid base
$ git rebase -i master
Interactive rebase already started
$ git rebase --abort
fatal: Needed a single revision
# Even though rebase --abort reports an error, rebase's internal state
is now cleared
Regards,
Ulrik Sverdrup
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Linus Torvalds @ 2007-12-19 1:16 UTC (permalink / raw)
To: Dana How
Cc: Johannes Schindelin, Alex Riesen, Jakub Narebski, git,
Junio C Hamano
In-Reply-To: <56b7f5510712181503l1e5dcacds23511d968f98aedb@mail.gmail.com>
On Tue, 18 Dec 2007, Dana How wrote:
>
> Both of your counterexamples use 2 disjoint directory trees:
> C: vs D:, or trees on different machines.
>
> The cases we are talking about are all subtrees of the working tree.
> There is a useful cwd suffix.
No.
The cases we're talking of are *not* subtrees of the working tree.
The SHA1 of a commit may well be a totally disjoint tree. Try it in the
git repository with something like
git show origin/man:man1/git-fsck.1
or
git show origin/todo:TODO
and realize that Dscho's examples of using the DOS/Windows drive letters
is actually a really good example of what that <commit>:<pathname> syntax
is.
In fact, you can very well think of the commit/tree as a "drive letter".
It really does go into another namespace entirely. It's just that often
that namespace does bear some relationship to the currently checked out
branch. But that's just an "often", it's not at all a given.
> Don't you think that
> git <op> commit:./file.c
> could occasionally be more convenient than
> git <op> commit:very/long/and/boring/path/equal/to/cwd/file.c
It's not about "convenience". It's about *sanity* and good design. And the
fact is, that "commit:path" format really has nothing to do with the CWD
in the general case.
Linus
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Dana How @ 2007-12-19 1:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Alex Riesen, Jakub Narebski, git, danahow
In-Reply-To: <alpine.LFD.0.9999.0712181711100.21557@woody.linux-foundation.org>
On Dec 18, 2007 5:16 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 18 Dec 2007, Dana How wrote:
> > The cases we are talking about are all subtrees of the working tree.
> > There is a useful cwd suffix.
>
> No.
>
> The cases we're talking of are *not* subtrees of the working tree.
>
> The SHA1 of a commit may well be a totally disjoint tree. Try it in the
> git repository with something like
Agreed, but note you wrote *may*.
I'd like to move some stuff currently in a p4 repository into git.
The directory structure within the repo is 13 levels deep;
I didn't design it nor can I change it.
For the majority of the cases of interest to me git already accepts
relative paths. However, one thing people do often in p4 (or any SCM)
is look at (or compare, etc) specific revisions. Unfortunately, these are
not part of branches or commits, they are just file-specific revisions
(don't get me started on p4 "branches"). The equivalent in git is
to use a commit name (or a tag) and then name the file. The
basic commit:file syntax doesn't accept relative paths. I am not
specifically hung up on the commit:./path syntax; I just want some
notation that will get those 13 directories from $cwd instead of
making me type them again. Yes, sometimes that might not make
sense to request.
There was some mention of bash/zsh completions Unfortunately,
much of our CAD environment is not configured in bash/zsh,
so although I use bash for some scripting,
it's not the default for command-line, and won't be used by
others I need to drag along with me...
> In fact, you can very well think of the commit/tree as a "drive letter".
> It really does go into another namespace entirely. It's just that often
> that namespace does bear some relationship to the currently checked out
> branch. But that's just an "often", it's not at all a given.
>
> > Don't you think that
> > git <op> commit:./file.c
> > could occasionally be more convenient than
> > git <op> commit:very/long/and/boring/path/equal/to/cwd/file.c
>
> It's not about "convenience". It's about *sanity* and good design. And the
> fact is, that "commit:path" format really has nothing to do with the CWD
> in the general case.
Yes I frequently get to be one of the people here pushing for
(and sometimes losing the case for) "good design".
But I will never be able to successfully argue for retyping 13 directories
already in the cwd because it's the "good" or "sane" thing to do.
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.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
(Junio removed from cc: at his request)
^ permalink raw reply
* bug with .gitattributes diff and embedded NUL
From: Eric Blake @ 2007-12-19 5:07 UTC (permalink / raw)
To: git
The man page for gitattributes suggests that one use of the diff attribute
is to force text-based diffs, even when the file contains embedded NULs.
Yet actually trying this falls flat, since git generates invalid diffs
when encountering embedded NUL.
Here is a pared-down example showing the bug. I based it off of what I
was trying to do in the git repository for GNU m4, where I was working on
adding testcases to make m4 seamlessly handle embedded NUL.
$ git --version
git version 1.5.4.rc0.67.gf9c5
$ mkdir sample
$ cd sample
$ git init
Initialized empty Git repository in .git/
$ printf 'context with\0embedded nul\nbefore\nmore context\n' > file
$ git add file
$ git commit -m initial
Created initial commit 25108f6: initial
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file
$ git tag t1
$ sed -i 's/before/after/' file
$ git add file
$ git commit -m later
Created commit a5ee10c: later
1 files changed, 0 insertions(+), 0 deletions(-)
$ git tag t2
$ git reset --hard t1
HEAD is now at 25108f6... initial
$ sed -i 's/more/some &/' file
$ echo 'file diff' > .gitattributes
$ git add .gitattributes file
$ git commit -m 'switch file to text mode'
Created commit 0f2a9b2: switch file to text mode
2 files changed, 2 insertions(+), 1 deletions(-)
create mode 100644 .gitattributes
$ git tag t3
$ git reset --hard t2
HEAD is now at a5ee10c... later
$ git rebase --onto t3 t1
First, rewinding head to replay your work on top of it...
HEAD is now at 0f2a9b2... switch file to text mode
Applying later
error: patch failed: file:1
error: file: patch does not apply
Using index info to reconstruct a base tree...
error: patch failed: file:1
error: file: patch does not apply
Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Cannot fall back to three-way merge.
Patch failed at 0001.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
Looking closer at .dotest/0001, the diff is indeed invalid, containing the
single line
context with-before
instead of the desired two lines
context with^@embedded nul
-before
I'm also wondering if using GIT_EXTERNAL_DIFF would provide a way to work
around this bug in git diff, since GNU diffutils doesn't seem to have any
problems when doing text-mode diffs with embedded NUL:
$ diff -u -a <(git show t1:file) <(git show t2:file) | cat -v
--- /dev/fd/63 2006-11-30 17:00:00.000000000 -0700
+++ /dev/fd/62 2006-11-30 17:00:00.000000000 -0700
@@ -1,3 +1,3 @@
context with^@embedded nul
-before
+after
more context
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
^ permalink raw reply
* Re: bug with .gitattributes diff and embedded NUL
From: Junio C Hamano @ 2007-12-19 6:40 UTC (permalink / raw)
To: Eric Blake; +Cc: git
In-Reply-To: <4768A70F.8020904@byu.net>
Eric Blake <ebb9@byu.net> writes:
> Looking closer at .dotest/0001, the diff is indeed invalid, containing the
> single line
That is not a bug in diff but actually in bug in non-merge form of
rebase, which reuses "format patch as if we are sending it out in
e-mail, and apply that on top of a different commit as if we are
accepting that e-mail" machinery. That dataflow loses NUL. Fixing
rebase not to reuse the e-mailed patch dataflow is on my to-do list, but
has been slipping.
So, no, I do not think GIT_EXTERNAL_DIFF would help, as the problem is
not diff generation.
I think you can use "rebase -m" to work this issue around.
^ permalink raw reply
* [PATCH 1/2] Avoid update hook during git-rebase --interactive
From: Shawn O. Pearce @ 2007-12-19 6:41 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
If we are rebasing changes that contain potential whitespace
errors that our .git/hooks/pre-commit hook looks for and fails
on then git-commit will fail to commit that change. This causes
git-rebase--interactive to squash commits together, even though it
was not requested to do so by the todo file.
Passing --no-verify to git-commit makes git-rebase -i behave more
like git-rebase normally would in such conditions, providing more
consistent behavior between the different rebase implementations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This bug has bitten me more than once. One could argue that the
pre-commit hook should be running, to prevent you from rebasing a
series that has crappy whitespace, but git-rebase without -m and
without -i will let you rebase such a series without stopping you,
as git-am doesn't execute the pre-commit hook.
git-rebase--interactive.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index cd7e43f..b846ea8 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -296,7 +296,7 @@ do_next () {
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
- $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
+ $USE_OUTPUT git commit --no-verify -F "$MSG" $EDIT_COMMIT
;;
t)
cp "$MSG" "$GIT_DIR"/MERGE_MSG
@@ -372,7 +372,7 @@ do
test ! -f "$DOTEST"/amend || git reset --soft HEAD^
} &&
export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
- git commit -F "$DOTEST"/message -e
+ git commit --no-verify -F "$DOTEST"/message -e
require_clean_work_tree
do_rest
--
1.5.4.rc0.1155.g12ed9
^ permalink raw reply related
* [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
* 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
* 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] 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: 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: [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: 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: 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: 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: 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: [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 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] 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: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] 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
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