* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Andreas Ericsson @ 2011-10-13 12:22 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T130924-792@post.gmane.org>
On 10/13/2011 01:51 PM, arQon wrote:
> Snipping the bug and focusing on one of the after-effects of the bug is,
> unfortunately, not helpful to me unless I'm missing your point (which is
> certainly possible).
>
> git switched branches while there were uncommitted files. It's not supposed to
> do this, ever, unless given -f or -m, and it broke the tree as a result. Even
> *with* -f or -m, the behavior I described is incorrect.
> The git docs seem to agree with me, which is why there's git stash. If the docs
> are wrong, fine, though it seems pretty strange to have a change on BranchA
> appear by magic "in" BranchB without any merging.
>
> What I'm after is an understanding / explanation of how something that isn't
> supposed to happen, does. I don't care if it's "Because I'm an idiot", "Because
> git is broken", or even "Make sure your config has 'git.makebranchesworkproperly
> = true' in it, the default is false". If there is no explanation for why git
> switches branches when there are still uncommitted files, and there doesn't seem
> to be, then it's a pretty catastrophic bug and fixing it would be a Good Thing.
>
> *AFAICT*, committing *a* file is what triggers it.
> If you commit -a, which is what all the commits prior to this were, it works
> properly. You change branches, and the files on the disk become what they should
> be.
> If you commit nothing, you correctly get the "uncommitted files" error.
> If you do a partial commit though, your tree breaks.
>
> Like I say, if the man page, quote:
> "If you have local modifications to one or more files that are different between
> the current branch and the branch to which you are switching, the command
> refuses to switch branches in order to preserve your modifications in context."
This means that if fileX on branchA is different from fileX on branchB and you
*also* have local modifications to fileX, git will refuse to switch branches.
If, on the other hand branchA:fileX == branchB:fileX and you have modifications
to fileX in your work tree, there's no reason to refuse the branch change.
Partly because nothing will be lost and partly because you can just switch
branches back if you decide you've switched branches before committing things
to the first branch.
> is wrong, and this behavior is deliberate, that's fine. Bizarre, but fine in
> the sense that git is doing what it's supposed to (regardless of how
> counterintuitive and destructive it is).
> If the man page is right though, this is a bug. Maybe it's only in msysgit,
> but this is the second time it's happened, so hopefully it's fairly easy to
> reproduce.
>
It's not a bug. You just read the manpage a bit wrong.
Consider this scenario:
$dev works on featureA on branchA, modifying fileX, fileZ and fileY and then
does a commit of fileZ and fileY, but realizes that the changes in fileX
will be good for developing featureB as well, so he changes to a separate
branch to do the update to fileX and be able to merge those changes to
both branchA and branchB.
I've done this myself on numerous occasions when re-working small project-
local API's, and it's very, very handy indeed. If git would refuse me to
change branches without first committing everything I'd have to first
commit the change separately, switch branch, cherrypick the change, go
back to the first branch and remove the commit I made there, merge the
other branch where the commit really belonged and only then I could go
on about my business. If, on the other hand, I happen to switch branches
before committing fileZ in the above example, I can just switch back and
amend my last commit on the first branch.
So yes, this is a feature, and it's a handy one.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH 07/14] is_refname_available(): remove the "quiet" argument
From: Drew Northup @ 2011-10-13 12:41 UTC (permalink / raw)
To: mhagger
Cc: Junio C Hamano, git, Jeff King, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips
In-Reply-To: <1318492715-5931-8-git-send-email-mhagger@alum.mit.edu>
On Thu, 2011-10-13 at 09:58 +0200, mhagger@alum.mit.edu wrote:
> From: Michael Haggerty <mhagger@alum.mit.edu>
>
> quiet was always set to 0, so get rid of it. Add a function docstring
> for good measure.
I would like to know if perhaps it was an unfinished project somewhere
to propagate the "quiet" option down to this level before removing the
function argument. Comments?
> +/*
> + * Return true iff a reference named refname could be created without
Did you really mean "iff" (as in "if and only if") or just plain "if"
here?
> + * conflicting with the name of an existing reference. If oldrefname
> + * is non-NULL, ignore potential conflicts with oldrefname (e.g.,
> + * because oldrefname is scheduled for deletion in the same
> + * operation).
> + */
> static int is_refname_available(const char *refname, const char *oldrefname,
> - struct ref_array *array, int quiet)
> + struct ref_array *array)
> {
> int i, namlen = strlen(refname); /* e.g. 'foo/bar' */
> for (i = 0; i < array->nr; i++ ) {
> @@ -1062,9 +1069,8 @@ static int is_refname_available(const char *refname, const char *oldrefname,
> const char *lead = (namlen < len) ? entry->name : refname;
> if (!strncmp(refname, entry->name, cmplen) &&
> lead[cmplen] == '/') {
> - if (!quiet)
> - error("'%s' exists; cannot create '%s'",
> - entry->name, refname);
> + error("'%s' exists; cannot create '%s'",
> + entry->name, refname);
> return 0;
> }
> }
> @@ -1117,7 +1123,7 @@ static struct ref_lock *lock_ref_sha1_basic(const char *refname,
> * name is a proper prefix of our refname.
> */
> if (missing &&
> - !is_refname_available(refname, NULL, get_packed_refs(NULL), 0)) {
> + !is_refname_available(refname, NULL, get_packed_refs(NULL))) {
> last_errno = ENOTDIR;
> goto error_return;
> }
> @@ -1272,10 +1278,10 @@ int rename_ref(const char *oldrefname, const char *newrefname, const char *logms
> if (!symref)
> return error("refname %s not found", oldrefname);
>
> - if (!is_refname_available(newrefname, oldrefname, get_packed_refs(NULL), 0))
> + if (!is_refname_available(newrefname, oldrefname, get_packed_refs(NULL)))
> return 1;
>
> - if (!is_refname_available(newrefname, oldrefname, get_loose_refs(NULL), 0))
> + if (!is_refname_available(newrefname, oldrefname, get_loose_refs(NULL)))
> return 1;
>
> lock = lock_ref_sha1_basic(renamed_ref, NULL, 0, NULL);
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: arQon @ 2011-10-13 12:42 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111013T130924-792@post.gmane.org>
Simple testcase:
>git init
Initialized empty Git repository in C:/git-test/.git/
>notepad file1
>notepad file2
>git st
# On branch master
# Initial commit
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# file1.txt
# file2.txt
nothing added to commit but untracked files present (use "git add" to track)
>git add .
>git st
# On branch master
# Initial commit
# Changes to be committed:
# new file: file1.txt
# new file: file2.txt
>git commit -am "init"
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 file1.txt
create mode 100644 file2.txt
>git co -b foo
Switched to a new branch 'foo'
>notepad file1
(edit stuff)
>git st
# On branch foo
# Changes not staged for commit:
# modified: file1.txt
>git co master
M file1.txt
file1 now has the wrong data in it for "master" branch.
If I go back to "foo" branch and commit the file before doing anything else,
it recovers, and changing branches works correctly again.
--
"If you have local modifications to one or more files that are different
between the current branch and the branch to which you are switching, the
command refuses to switch branches in order to preserve your modifications
in context."
Maybe I'm just missing something obvious, but at the time that last "git
co master" was issued:
The file is locally modified.
The file is different on the current branch (foo) than on the branch to which
I am switching (master).
The command fails to refuse to switch branches.
So I guess the problem is that since the file wasn't re-added after the edit,
git is ignoring it when trying to see if it's safe to branch or not?
^ permalink raw reply
* [PATCH 1/2] submodule: Demonstrate known breakage during recursive merge
From: Brad King @ 2011-10-13 12:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Heiko Voigt
In-Reply-To: <cover.1318509069.git.brad.king@kitware.com>
Since commit 68d03e4a (Implement automatic fast-forward merge for
submodules, 2010-07-07) we try to suggest submodule commits that resolve
a conflict. Consider a true recursive merge case
b---bc
/ \ /
o X
\ / \
c---cb
in which the two heads themselves (bc,cb) had resolved a submodule
conflict (i.e. reference different commits than their parents). The
submodule merge search runs during the temporary merge of the two merge
bases (b,c) and prints out a suggestion that is not meaningful to the
user. Then during the main merge the submodule merge search runs again
but dies with the message
fatal: --ancestry-path given but there are no bottom commits
while trying to enumerate candidates. Demonstrate this known breakage
with a new test in t7405-submodule-merge covering the case.
Signed-off-by: Brad King <brad.king@kitware.com>
---
t/t7405-submodule-merge.sh | 51 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh
index a8fb30b..14da2e3 100755
--- a/t/t7405-submodule-merge.sh
+++ b/t/t7405-submodule-merge.sh
@@ -228,4 +228,55 @@ test_expect_success 'merging with a modify/modify conflict between merge bases'
git merge d
'
+# canonical criss-cross history in top and submodule
+test_expect_success 'setup for recursive merge with submodule' '
+ mkdir merge-recursive &&
+ (cd merge-recursive &&
+ git init &&
+ mkdir sub &&
+ (cd sub &&
+ git init &&
+ test_commit a &&
+ git checkout -b sub-b master &&
+ test_commit b &&
+ git checkout -b sub-c master &&
+ test_commit c &&
+ git checkout -b sub-bc sub-b &&
+ git merge sub-c &&
+ git checkout -b sub-cb sub-c &&
+ git merge sub-b &&
+ git checkout master) &&
+ git add sub &&
+ git commit -m a &&
+ git checkout -b top-b master &&
+ (cd sub && git checkout sub-b) &&
+ git add sub &&
+ git commit -m b &&
+ git checkout -b top-c master &&
+ (cd sub && git checkout sub-c) &&
+ git add sub &&
+ git commit -m c &&
+ git checkout -b top-bc top-b &&
+ git merge -s ours --no-commit top-c &&
+ (cd sub && git checkout sub-bc) &&
+ git add sub &&
+ git commit -m bc &&
+ git checkout -b top-cb top-c &&
+ git merge -s ours --no-commit top-b &&
+ (cd sub && git checkout sub-cb) &&
+ git add sub &&
+ git commit -m cb)
+'
+
+# merge should leave submodule unmerged in index
+test_expect_failure 'recursive merge with submodule' '
+ (cd merge-recursive &&
+ test_must_fail git merge top-bc &&
+ echo "160000 $(git rev-parse top-cb:sub) 2 sub" > expect2 &&
+ echo "160000 $(git rev-parse top-bc:sub) 3 sub" > expect3 &&
+ git ls-files -u > actual &&
+ grep "$(cat expect2)" actual > /dev/null &&
+ grep "$(cat expect3)" actual > /dev/null)
+'
+
test_done
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/2] Do not search submodules in deep recursive merge
From: Brad King @ 2011-10-13 12:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Heiko Voigt
In-Reply-To: <7vipnu9hbj.fsf@alter.siamese.dyndns.org>
On 10/12/2011 2:48 PM, Junio C Hamano wrote:
> [Stalled]
>
> * hv/submodule-merge-search (2011-08-26) 5 commits
> - submodule: Search for merges only at end of recursive merge
> - allow multiple calls to submodule merge search for the same path
> - submodule: Demonstrate known breakage during recursive merge
> - push: Don't push a repository with unpushed submodules
> - push: teach --recurse-submodules the on-demand option
> (this branch is tangled with fg/submodule-auto-push.)
AFAICT these two topics are tangled due revision traversal interactions.
I've untangled the two "submodule:" commits from this stalled topic and
rebased on master (34c4461a) resolving one conflict.
The first commit demonstrates a bug: submodule merge search occurs
multiple times for the same path during a recursive merge and fails the
second time. The second commit fixes it by performing the merge search
only at depth 0 recursion. These changes are independent from the
actual merge search and revision traversal logic.
Brad
Brad King (2):
submodule: Demonstrate known breakage during recursive merge
submodule: Search for merges only at end of recursive merge
merge-recursive.c | 6 +++-
submodule.c | 6 ++++-
submodule.h | 2 +-
t/t7405-submodule-merge.sh | 51 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 61 insertions(+), 4 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 2/2] submodule: Search for merges only at end of recursive merge
From: Brad King @ 2011-10-13 12:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Heiko Voigt
In-Reply-To: <cover.1318509069.git.brad.king@kitware.com>
The submodule merge search is not useful during virtual merges because
the results cannot be used automatically. Furthermore any suggestions
made by the search may apply to commits different than HEAD:sub and
MERGE_HEAD:sub, thus confusing the user. Skip searching for submodule
merges during a virtual merge such as that between B and C while merging
the heads of:
B---BC
/ \ /
A X
\ / \
C---CB
Run the search only when the recursion level is zero (!o->call_depth).
This fixes known breakage tested in t7405-submodule-merge.
Signed-off-by: Brad King <brad.king@kitware.com>
---
merge-recursive.c | 6 ++++--
submodule.c | 6 +++++-
submodule.h | 2 +-
t/t7405-submodule-merge.sh | 2 +-
4 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index c34a4f1..cc664c3 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -946,8 +946,10 @@ static struct merge_file_info merge_file_1(struct merge_options *o,
free(result_buf.ptr);
result.clean = (merge_status == 0);
} else if (S_ISGITLINK(a->mode)) {
- result.clean = merge_submodule(result.sha, one->path, one->sha1,
- a->sha1, b->sha1);
+ result.clean = merge_submodule(result.sha,
+ one->path, one->sha1,
+ a->sha1, b->sha1,
+ !o->call_depth);
} else if (S_ISLNK(a->mode)) {
hashcpy(result.sha, a->sha1);
diff --git a/submodule.c b/submodule.c
index 0b709bc..0fd10a0 100644
--- a/submodule.c
+++ b/submodule.c
@@ -794,7 +794,7 @@ static void print_commit(struct commit *commit)
int merge_submodule(unsigned char result[20], const char *path,
const unsigned char base[20], const unsigned char a[20],
- const unsigned char b[20])
+ const unsigned char b[20], int search)
{
struct commit *commit_base, *commit_a, *commit_b;
int parent_count;
@@ -849,6 +849,10 @@ int merge_submodule(unsigned char result[20], const char *path,
* user needs to confirm the resolution.
*/
+ /* Skip the search if makes no sense to the calling context. */
+ if (!search)
+ return 0;
+
/* find commit which merges them */
parent_count = find_first_merges(&merges, path, commit_a, commit_b);
switch (parent_count) {
diff --git a/submodule.h b/submodule.h
index 799c22d..80e04f3 100644
--- a/submodule.h
+++ b/submodule.h
@@ -28,7 +28,7 @@ int fetch_populated_submodules(int num_options, const char **options,
int quiet);
unsigned is_submodule_modified(const char *path, int ignore_untracked);
int merge_submodule(unsigned char result[20], const char *path, const unsigned char base[20],
- const unsigned char a[20], const unsigned char b[20]);
+ const unsigned char a[20], const unsigned char b[20], int search);
int check_submodule_needs_pushing(unsigned char new_sha1[20], const char *remotes_name);
#endif
diff --git a/t/t7405-submodule-merge.sh b/t/t7405-submodule-merge.sh
index 14da2e3..0d5b42a 100755
--- a/t/t7405-submodule-merge.sh
+++ b/t/t7405-submodule-merge.sh
@@ -269,7 +269,7 @@ test_expect_success 'setup for recursive merge with submodule' '
'
# merge should leave submodule unmerged in index
-test_expect_failure 'recursive merge with submodule' '
+test_expect_success 'recursive merge with submodule' '
(cd merge-recursive &&
test_must_fail git merge top-bc &&
echo "160000 $(git rev-parse top-cb:sub) 2 sub" > expect2 &&
--
1.7.5.4
^ permalink raw reply related
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: arQon @ 2011-10-13 13:09 UTC (permalink / raw)
To: git
In-Reply-To: <4E96D819.20905@op5.se>
Andreas Ericsson <ae <at> op5.se> writes:
[snip]
> This means that if fileX on branchA is different from fileX on branchB and you
> *also* have local modifications to fileX, git will refuse to switch branches.
> If, on the other hand branchA:fileX == branchB:fileX and you have modifications
> to fileX in your work tree, there's no reason to refuse the branch change.
There's an EXCELLENT reason to refuse the branch change: once it happens, what
git is then telling is branchA, is not.
> It's not a bug. You just read the manpage a bit wrong.
[snip]
> So yes, this is a feature, and it's a handy one.
Thanks for the explanation. Unfortunately, I still can't see it as anything but
a critical bug. Consider this:
You're working on branchA and you have a bunch of uncommitted changes.
You can't remember some detail of the bug you're fixing, so you switch branches
to the master. You have to rebuild that branch, because your last build was from
your branch. git now builds the master with sources that were NEVER committed
to it. How is that not a total failure to maintain branch integrity?
If that's the way git is, then that's how it is; and if there isn't a setting
that can make it actually preserve branches properly, then there isn't. Which
sucks for me, because an SCCS that lies about what branch you're "really" on
is worse than useless, so I'm stuck with SVN. :(
Thanks again for clearing it up for me though.
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Holger Hellmuth @ 2011-10-13 12:55 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T141239-151@post.gmane.org>
On 13.10.2011 14:42, arQon wrote:
>> git co -b foo
> Switched to a new branch 'foo'
>> notepad file1
> (edit stuff)
>> git st
> # On branch foo
> # Changes not staged for commit:
> # modified: file1.txt
>
>> git co master
> M file1.txt
>
> Maybe I'm just missing something obvious, but at the time that last "git
> co master" was issued:
>
> The file is locally modified.
> The file is different on the current branch (foo) than on the branch to which
> I am switching (master).
Wrong. On branch foo as well as on master the same old file1.txt is
committed. You never staged nor committed the new file1.txt anywhere.
> The command fails to refuse to switch branches.
^ permalink raw reply
* Re: Git attributes ignored for root directory
From: Johannes Sixt @ 2011-10-13 13:16 UTC (permalink / raw)
To: Gioele Barabucci; +Cc: Junio C Hamano, Michael Haggerty, git
In-Reply-To: <4E96C220.5050601@svario.it>
Am 10/13/2011 12:49, schrieb Gioele Barabucci:
> I see that `/*/` in `.gitignores` successfully ignores all the non-hidden
> directories in the root project directory. Another accidental success? :)
No, that's by design. The first slash means "apply only in this directory,
not any subdirectories", and the slash at the end means "match only if the
name is a directory".
-- Hannes
^ permalink raw reply
* Re: git rebase +
From: Johannes Sixt @ 2011-10-13 13:21 UTC (permalink / raw)
To: Adam Piatyszek; +Cc: git
In-Reply-To: <loom.20111013T134405-495@post.gmane.org>
Am 10/13/2011 13:48, schrieb Adam Piatyszek:
> In the middle of "git rebase --continue" process I hit Ctrl+C today to break
> this operation. When I tried to replay the same command it errors out with the
> following problem:
> /project/dfttools/libexec/git-core/git-rebase--interactive: line 650:
> /home/ediap/project.git/.git/rebase-merge/author-script: No such file or
> directory
>
> Is this an expected behavior?
Hitting Ctrl-C during git-rebase results undefined behavior. git-rebase is
a shell script and was never designed to operate in any form of atomicity.
You should have let it run until it stopped. Then you could have said 'git
rebase --abort' (if it didn't complete) or 'git reset --hard ORIG_HEAD'
(if it completed).
-- Hannes
^ permalink raw reply
* [PATCH 1/4] git-gui: search and linenumber input are mutual exclusive in the blame view
From: Bert Wesarg @ 2011-10-13 13:48 UTC (permalink / raw)
To: Pat Thoyts; +Cc: David Fries, git, Bert Wesarg
It was possible to open the search input (Ctrl+S) and the goto-line input
(Ctrl+G) at the same time. Prevent this.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/blame.tcl | 22 ++++++++++++++++------
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/lib/blame.tcl b/lib/blame.tcl
index 2099776..691941e 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -280,11 +280,11 @@ constructor new {i_commit i_path i_jump} {
$w.ctxm add command \
-label [mc "Find Text..."] \
-accelerator F7 \
- -command [list searchbar::show $finder]
+ -command [cb _show_finder]
$w.ctxm add command \
-label [mc "Goto Line..."] \
-accelerator "Ctrl-G" \
- -command [list linebar::show $gotoline]
+ -command [cb _show_linebar]
menu $w.ctxm.enc
build_encoding_menu $w.ctxm.enc [cb _setencoding]
$w.ctxm add cascade \
@@ -351,13 +351,13 @@ constructor new {i_commit i_path i_jump} {
bind $w_cviewer <Tab> "[list focus $w_file];break"
bind $w_cviewer <Button-1> [list focus $w_cviewer]
bind $w_file <Visibility> [cb _focus_search $w_file]
- bind $top <F7> [list searchbar::show $finder]
- bind $top <Key-slash> [list searchbar::show $finder]
- bind $top <Control-Key-s> [list searchbar::show $finder]
+ bind $top <F7> [cb _show_finder]
+ bind $top <Key-slash> [cb _show_finder]
+ bind $top <Control-Key-s> [cb _show_finder]
bind $top <Escape> [list searchbar::hide $finder]
bind $top <F3> [list searchbar::find_next $finder]
bind $top <Shift-F3> [list searchbar::find_prev $finder]
- bind $top <Control-Key-g> [list linebar::show $gotoline]
+ bind $top <Control-Key-g> [cb _show_linebar]
catch { bind $top <Shift-Key-XF86_Switch_VT_3> [list searchbar::find_prev $finder] }
grid configure $w.header -sticky ew
@@ -1349,4 +1349,14 @@ method _resize {new_height} {
set old_height $new_height
}
+method _show_finder {} {
+ linebar::hide $gotoline
+ searchbar::show $finder
+}
+
+method _show_linebar {} {
+ searchbar::hide $finder
+ linebar::show $gotoline
+}
+
}
--
1.7.6.789.gb4599
^ permalink raw reply related
* [PATCH 3/4] git-gui: only except numbers in the goto-line input
From: Bert Wesarg @ 2011-10-13 13:48 UTC (permalink / raw)
To: Pat Thoyts; +Cc: David Fries, git, Bert Wesarg
In-Reply-To: <1d1c91fdaa0bfd31067fd2e06f3f1ecf5597b8d3.1318513492.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/line.tcl | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/lib/line.tcl b/lib/line.tcl
index 692485a..70785e1 100644
--- a/lib/line.tcl
+++ b/lib/line.tcl
@@ -15,7 +15,11 @@ constructor new {i_w i_text args} {
${NS}::frame $w
${NS}::label $w.l -text [mc "Goto Line:"]
- entry $w.ent -textvariable ${__this}::linenum -background lightgreen
+ entry $w.ent \
+ -textvariable ${__this}::linenum \
+ -background lightgreen \
+ -validate key \
+ -validatecommand [cb _validate %P]
${NS}::button $w.bn -text [mc Go] -command [cb _incrgoto]
pack $w.l -side left
@@ -26,7 +30,7 @@ constructor new {i_w i_text args} {
grid remove $w
bind $w.ent <Return> [cb _incrgoto]
- bind $w.ent <Escape> [list linebar::hide $this]
+ bind $w.ent <Escape> [cb hide]
bind $w <Destroy> [list delete_this $this]
return $this
@@ -55,6 +59,14 @@ method editor {} {
return $w.ent
}
+method _validate {P} {
+ # only accept numbers as input
+ if {[regexp {\d*} $P]} {
+ return 1
+ }
+ return 0
+}
+
method _incrgoto {} {
if {$linenum ne {}} {
$ctext see $linenum.0
--
1.7.6.789.gb4599
^ permalink raw reply related
* [PATCH 2/4] git-gui: clear the goto line input when hiding
From: Bert Wesarg @ 2011-10-13 13:48 UTC (permalink / raw)
To: Pat Thoyts; +Cc: David Fries, git, Bert Wesarg
In-Reply-To: <1d1c91fdaa0bfd31067fd2e06f3f1ecf5597b8d3.1318513492.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/line.tcl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/line.tcl b/lib/line.tcl
index 4913bdd..692485a 100644
--- a/lib/line.tcl
+++ b/lib/line.tcl
@@ -41,6 +41,7 @@ method show {} {
method hide {} {
if {[visible $this]} {
+ $w.ent delete 0 end
focus $ctext
grid remove $w
}
--
1.7.6.789.gb4599
^ permalink raw reply related
* [RFC/PATCH 4/4] git-gui: incremental goto line in blame view
From: Bert Wesarg @ 2011-10-13 13:48 UTC (permalink / raw)
To: Pat Thoyts; +Cc: David Fries, git, Bert Wesarg
In-Reply-To: <1d1c91fdaa0bfd31067fd2e06f3f1ecf5597b8d3.1318513492.git.bert.wesarg@googlemail.com>
The view jumps now to the given line number after each key press.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
I didn't know this before, but gedits goto-line-dialog works this way.
lib/line.tcl | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/lib/line.tcl b/lib/line.tcl
index 70785e1..0113e06 100644
--- a/lib/line.tcl
+++ b/lib/line.tcl
@@ -20,7 +20,7 @@ constructor new {i_w i_text args} {
-background lightgreen \
-validate key \
-validatecommand [cb _validate %P]
- ${NS}::button $w.bn -text [mc Go] -command [cb _incrgoto]
+ ${NS}::button $w.bn -text [mc Go] -command [cb _goto]
pack $w.l -side left
pack $w.bn -side right
@@ -29,7 +29,8 @@ constructor new {i_w i_text args} {
eval grid conf $w -sticky we $args
grid remove $w
- bind $w.ent <Return> [cb _incrgoto]
+ trace add variable linenum write [cb _goto_cb]
+ bind $w.ent <Return> [cb _goto]
bind $w.ent <Escape> [cb hide]
bind $w <Destroy> [list delete_this $this]
@@ -67,10 +68,16 @@ method _validate {P} {
return 0
}
-method _incrgoto {} {
+method _goto_cb {name ix op} {
+ after idle [cb _goto 1]
+}
+
+method _goto {{nohide {0}}} {
if {$linenum ne {}} {
$ctext see $linenum.0
- hide $this
+ if {!$nohide} {
+ hide $this
+ }
}
}
--
1.7.6.789.gb4599
^ permalink raw reply related
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: arQon @ 2011-10-13 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <4E96D819.20905@op5.se>
Andreas Ericsson <ae <at> op5.se> writes:
> there's no reason to refuse the branch change.
> Partly because nothing will be lost
Actually, this isn't true either, because of the second bug: doing a revert
in branchA causes the changes in branchB to be lost. This can't possibly be
the intended behavior: again, it completely violates the integrity of branches
by allowing changes on one branch to impact a different branch.
Your interpretation of the manpage doubtless matches the actual behavior of git,
but I find it staggering if that truly is what was intended. It basically means
that if you have local modifications, git will Break Your Entire Tree. That
makes changing while you *do* have local mods more than a little undesirable,
to put it mildly, which is something that a literal reading of the manpage would
suggest is exactly what the "refuse to switch" is for. I guess only Linus knows
what he actually meant. :)
Anyway, I guess it's all moot: call it a feature or call it a bug, this cross-
branch destruction is a deal-breaker for me, especially given the bug above that
actually loses data outright, rather than "only" putting multiple branches into
an incorrect state.
Thanks for your time and help.
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Carlos Martín Nieto @ 2011-10-13 13:59 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T144822-277@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3195 bytes --]
On Thu, 2011-10-13 at 13:09 +0000, arQon wrote:
> Andreas Ericsson <ae <at> op5.se> writes:
> [snip]
> > This means that if fileX on branchA is different from fileX on branchB and you
> > *also* have local modifications to fileX, git will refuse to switch branches.
> > If, on the other hand branchA:fileX == branchB:fileX and you have modifications
> > to fileX in your work tree, there's no reason to refuse the branch change.
>
> There's an EXCELLENT reason to refuse the branch change: once it happens, what
> git is then telling is branchA, is not.
When you changed branches, git told you that a file had been changed in
the working tree. When you run 'git diff', it tells you the differences
between what you have in your working tree and what's in the branch[0].
Git is trying hard not to loose your modifications (maybe it was a
one-liner, maybe it was three hours of work) to the file.
>
> > It's not a bug. You just read the manpage a bit wrong.
> [snip]
> > So yes, this is a feature, and it's a handy one.
>
> Thanks for the explanation. Unfortunately, I still can't see it as anything but
> a critical bug. Consider this:
>
> You're working on branchA and you have a bunch of uncommitted changes.
> You can't remember some detail of the bug you're fixing, so you switch branches
> to the master. You have to rebuild that branch, because your last build was from
> your branch. git now builds the master with sources that were NEVER committed
> to it. How is that not a total failure to maintain branch integrity?
It sound like you've misunderstood what a branch is for git. A branch is
only ever changed when you commit. What checkout does is change what the
current branch is. For a case like what you describe, the developer
would either do a temporary commit that they'd change later or stash the
changes[1]. You could also use git-new-workdir (from contrib/) so you
have two different directories that share the object storage. That has a
few rough edges, but if you restrict it to a broken branch, you
shouldn't have any problems.
>
> If that's the way git is, then that's how it is; and if there isn't a setting
> that can make it actually preserve branches properly, then there isn't. Which
> sucks for me, because an SCCS that lies about what branch you're "really" on
> is worse than useless, so I'm stuck with SVN. :(
Don't think of it as being "in" a branch. A checkout in git changes the
active branch. If there are any files that are different between the two
branches, they are changed. By switching branches with uncommitted
changes, you're telling git that you would rather use the other branch
to do your changes in. But git isn't doing this silently. After the
checkout, it lists the files that have local modifications, so the
developer can switch branches again and commit or stash the changes.
cmn
[0] Really it's between the working tree and the index, but since you
just switched branches, the index is the same, and using it in that
sentence would just cause confusion.
[1] 'git stash' is a command that saves your uncommitted changes on a
stack so you can recover them later.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Victor Engmark @ 2011-10-13 14:44 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T141239-151@post.gmane.org>
On Thu, Oct 13, 2011 at 12:42:42PM +0000, arQon wrote:
> Simple testcase:
>
> >git init
> Initialized empty Git repository in C:/git-test/.git/
> >notepad file1
> >notepad file2
> >git st
> # On branch master
> # Initial commit
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> # file1.txt
> # file2.txt
> nothing added to commit but untracked files present (use "git add" to track)
>
> >git add .
> >git st
> # On branch master
> # Initial commit
> # Changes to be committed:
> # new file: file1.txt
> # new file: file2.txt
>
> >git commit -am "init"
> 2 files changed, 2 insertions(+), 0 deletions(-)
> create mode 100644 file1.txt
> create mode 100644 file2.txt
>
> >git co -b foo
> Switched to a new branch 'foo'
> >notepad file1
> (edit stuff)
> >git st
> # On branch foo
> # Changes not staged for commit:
> # modified: file1.txt
>
> >git co master
> M file1.txt
>
> file1 now has the wrong data in it for "master" branch.
The most important thing a VCS should do is to keep history intact.
That happens when you check out in Git: No branches were changed, only
the working space. The second most important thing a VCS should do is
not destroy any of your uncommitted work unless you tell it to. That
also happens when you check out in Git. The third most important thing a
VCS should do is facilitate the developer's workflow. One common thing
to do is to work on some thing, for example refactoring. During this
process you might realize that one of the changes actually fixed a bug
in the software. To keep things in their right place, you could now
either
1. `checkout master` and commit the fix there, then shift back and
continue working, or
2. commit the refactorings, `checkout master`, and commit the fix there.
Either of these are easy to do with Git. There really is no reason why
the changes in the workspace should be considered as "part of" the
currently active branch, because they *are* not.
Cheers,
V
--
terreActive AG
Kasinostrasse 30
CH-5001 Aarau
Tel: +41 62 834 00 55
Fax: +41 62 823 93 56
www.terreactive.ch
Wir sichern Ihren Erfolg - seit 15 Jahren
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Carlos Martín Nieto @ 2011-10-13 14:46 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T152144-60@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]
On Thu, 2011-10-13 at 13:58 +0000, arQon wrote:
> Andreas Ericsson <ae <at> op5.se> writes:
> > there's no reason to refuse the branch change.
> > Partly because nothing will be lost
>
> Actually, this isn't true either, because of the second bug: doing a revert
> in branchA causes the changes in branchB to be lost. This can't possibly be
> the intended behavior: again, it completely violates the integrity of branches
> by allowing changes on one branch to impact a different branch.
I have not seen a revert command in any of your messages. If a revert on
one branch changes another one, that would be a bug, but you haven't
shown this to happen.
>
> Your interpretation of the manpage doubtless matches the actual behavior of git,
> but I find it staggering if that truly is what was intended. It basically means
> that if you have local modifications, git will Break Your Entire Tree. That
> makes changing while you *do* have local mods more than a little undesirable,
> to put it mildly, which is something that a literal reading of the manpage would
> suggest is exactly what the "refuse to switch" is for. I guess only Linus knows
> what he actually meant. :)
Do not confuse a branch with a worktree. If you haven't committed yet,
those changes aren't in the branch (just like they wouldn't be in svn)
>
> Anyway, I guess it's all moot: call it a feature or call it a bug, this cross-
> branch destruction is a deal-breaker for me, especially given the bug above that
> actually loses data outright, rather than "only" putting multiple branches into
> an incorrect state.
I've just asked some subversion developers to confirm this, and then
tried it out myself: Subversion (my locally-installed version is 1.6.17,
latest stable) behaves the same way. Local modifications are carried
over across branches.
$ svn copy ^/trunk ^/branches/somebranch # Create a new branch
$ $EDITOR somefile # which exists in trunk and somebranch
$ svn switch ^/branches/somebranch
$ svn diff # My local changes are there!
The reason this happens both in svn and git is that the most likely
cause for someone to change a branch mid-edit is that they decide
they're doing the changes on the wrong branch. What I did notice is that
svn doesn't tell you about the modifications being carried over
(presumably you're meant to use status and diff to figure out what's
going on). Therefore, the same workflow (with the only difference being
how to create and switch branches) works for svn and git in this case.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Michael J Gruber @ 2011-10-13 15:09 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T094053-111@post.gmane.org>
arQon venit, vidit, dixit 13.10.2011 10:40:
> Which, as you'd expect, results in both the on-disk copies and other branches
> becoming corrupted.
>
> Tested on git versions 1.7.6 and 1.7.7 (msysgit)
>
> http://benno.id.au/blog/2011/10/01/git-recursive-merge-broken describes
> something that sounds similar, but that's supposedly fixed on 1.7.7,
> whereas this happens on that as well.
>
> master is a tracking branch, "ttfcon" is the branch I was using to develop
> a change. Got to a good point on the branch, merged it in:
>
> $ git co master
> $ git merge ttfcon
> Updating b9f0c75..6280b7a
> Fast-forward
> .gitignore | 2 ++
> code/renderer/tr_font.cpp | 27 ++++++++-------------------
> 2 files changed, 10 insertions(+), 19 deletions(-)
>
> $ git st
> # On branch master
> # Your branch is ahead of 'origin/master' by 3 commits.
>
> back to the branch to mess around with a couple of things to be sure this
> is what i want to push
> $ git co ttfcon
> do stuff
>
> $ git st
> # On branch ttfcon
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: code/freetype-2.3.11/builds/win32/visualc/freetype.vcproj
> # modified: code/renderer/tr_font.cpp
>
> so far so good...
>
> $ git ci -m "blah" code/freetype-2.3.11/builds/win32/visualc/freetype.vcproj
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> note that tr_font is locally modified and still *not committed* at this point.
and neither staged for commit, exactly.
> $ git co master
> M code/renderer/tr_font.cpp
> Switched to branch 'master'
> Your branch is ahead of 'origin/master' by 3 commits.
>
> boom. instead of rejecting the branch change, git switches branches anyway,
> and doesn't do anything about the uncommitted changes in the file itself -
Exactly. git leaves them as they are, without changing what you have in
your work tree.
(This is possible because the switch ttfcon to master involves no
changes which conflict with the chnage that you have in your work tree).
> meaning they're now effectively "in" master because they're still on disk,
> so now the master is poisoned.
Not at all. They are on "disk" (work tree). Full stop. Not staged, not
committed, not at all "in master".
>
> "git st" does show the change:
>
> # On branch master
> # Changes not staged for commit:
> # modified: code/renderer/tr_font.cpp
>
> but it's a change I never MADE on this branch (ie master), only on the
> other branch.
You never made it on the other branch either. You made it in the work
tree. And "git status" clearly says so: modified, not staged.
> "git diff" is just as confused as I am:
>
> $ git diff ttfcon
> --- a/code/renderer/tr_font.cpp
> +++ b/code/renderer/tr_font.cpp
> + // git branch bug
"git diff" shows you the change you have in your work tree, i.e. the
difference between index (which coincides with master since nothing is
staged) and work tree. The fact that there is a difference is equivalent
to saying "there are unstaged changes".
> So it's picking up the difference between the two branches, but as far as
No. The difference between the branches is the change to freetype.vcproj
because you committed that to ttfcon, not master.
> the *actual file* goes, master now has a line in it that shouldn't be there.
It's in the work tree, not master....
> I'm just trying out git as a possible replacement for SVN, so maybe I'm
> mistaken about what "should" happen, but AIUI git switching branches with
> uncommitted changes is a bug (and given that it poisoned a branch that I
> wasn't on, it certainly looks like one). A couple of days ago it DID complain
> when I tried to switch with uncommitted files still present, so it was working
> properly then. I have no idea what's made it happy to ignore them now:
> nothing's changed that I know of.
When switching branches, git tries to preserves the changes that you
have in your work tree. If it is possible (because there is no overlap,
as written above), it hapilly does just that. If not it barks.
I think you have to wrap your head around the Git model after unwinding
it from the svn model, which is normal ;)
Cheers,
Michael
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: arQon @ 2011-10-13 15:53 UTC (permalink / raw)
To: git
In-Reply-To: <1318517194.4646.30.camel@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn <at> elego.de> writes:
> I have not seen a revert command in any of your messages. If a revert on
> one branch changes another one, that would be a bug, but you haven't
> shown this to happen.
Sorry, it was in prose in the original post (near the end)
"At this point, reverting the master with "checkout --" also wipes out the
changes on the other branch. It's like the merge symlinked the two branches
rather than, well, merging them."
Based on the explanations here, and the git *st* message, it wiping out the
other branch is to be expected, because it's "the working directory", not
"the branch".
>git st
# On branch foo
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: file1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
What makes this really interesting though is this: I tried to switch to
master to see if that gave the same warning, and NOW, I get the correct
error.
>git co master
error: Your local changes to the following files would be overwritten by
checkout:
file1.txt
Please, commit your changes or stash them before you can switch branches.
Aborting
I'm sure if I thought about it enough (ie re-read Andreas's post a couple
more times) I'd be able to understand why git gets it right sometimes but
not other times, but I'm too tired right now. Even when I *am* awake and
grok it properly, I'm still going to be annoyed that it's so inconsistent,
but I can live with that if I have to.
> The reason this happens both in svn and git is that the most likely
> cause for someone to change a branch mid-edit is that they decide
> they're doing the changes on the wrong branch.
Lucky you. :P The most likely reason for me is, I'm working on something
and I get interrupted and have to switch. Since the code may well not even
compile at this point, the last thing I want to do is commit it. git's
ability for that commit to be local is half the reason I'm trying to switch
to it. (I'm not particularly keen on having to commit broken code to even a
local repo, but that's still a hell of a lot better than having it pushed
upstream as well).
> svn doesn't tell you about the modifications being carried over
> (presumably you're meant to use status and diff to figure out what's
> going on). Therefore, the same workflow (with the only difference being
> how to create and switch branches) works for svn and git in this case.
I expect part of my confusion comes from using different workdirs for svn
branches, ie "clone" rather than "branch", because branching in svn is such
a PITA I just don't bother with it unless the branch is going to be
"heavyweight" enough to warrant a "proper" branch.
Good to be reminded of though, thanks.
^ permalink raw reply
* Re: [Bug] git pull doesn't recognize --work-tree parameter
From: Jeff King @ 2011-10-13 15:59 UTC (permalink / raw)
To: Kirill Likhodedov; +Cc: Junio C Hamano, git
In-Reply-To: <E95C75ED-99F2-463C-A1AB-0F8152696739@jetbrains.com>
On Thu, Oct 13, 2011 at 12:38:53PM +0400, Kirill Likhodedov wrote:
> 'git pull' doesn't work from outside the working tree even if '--work-tree' is specified:
>
> # git version
> git version 1.7.6
> # git --git-dir=/Users/loki/sandbox/git/child/.git --work-tree=/Users/loki/sandbox/git/child pull
> fatal: /opt/local/libexec/git-core/git-pull cannot be used without a working tree.
>
> Note that 'git fetch' and 'git merge origin/master' work fine, so 'git pull' should be easy to fix :)
>
> # git --git-dir=/Users/loki/sandbox/git/child/.git --work-tree=/Users/loki/sandbox/git/child merge origin/master
> Already up-to-date.
This is a known issue, and the fix is a one-liner, but it needed
somebody to look through the pull script to make sure it wasn't
introducing any new bugs. I just did this; the patch below should fix
your problem.
-- >8 --
Subject: [PATCH] pull,rebase: handle GIT_WORK_TREE better
You can't currently run git-pull or git-rebase from outside
of the work tree, even with GIT_WORK_TREE set, due to an
overeager require_work_tree function. Commit e2eb527
documents this problem and provides the infrastructure for a
fix, but left it to later commits to audit and update
individual scripts.
Changing these scripts to use require_work_tree_exists is
easy to verify. We immediately call cd_to_toplevel, anyway.
Therefore no matter which function we use, the state
afterwards is one of:
1. We have a work tree, and we are at the top level.
2. We don't have a work tree, and we have died.
The only catch is that we must also make sure no code that
ran before the cd_to_toplevel assumed that we were already
in the working tree.
In this case, we will only have included shell libraries and
called set_reflog_action, neither of which care about the
current working directory at all.
Signed-off-by: Jeff King <peff@peff.net>
---
This is the low-hanging, obviously correct fruit. git-am and
git-stash also immediately cd_to_toplevel, but they look at
$PWD or `git rev-parse --show-prefix` beforehand, which
means those uses have to be audited separately.
git-pull.sh | 2 +-
git-rebase.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 63da37b..902fc4a 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -11,7 +11,7 @@ OPTIONS_SPEC=
. git-sh-setup
. git-sh-i18n
set_reflog_action "pull${1+ $*}"
-require_work_tree
+require_work_tree_exists
cd_to_toplevel
diff --git a/git-rebase.sh b/git-rebase.sh
index 6759702..00ca7b9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -63,7 +63,7 @@ skip! skip current patch and continue
"
. git-sh-setup
set_reflog_action rebase
-require_work_tree
+require_work_tree_exists
cd_to_toplevel
LF='
--
1.7.6.4.37.g43b58b
^ permalink raw reply related
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Holger Hellmuth @ 2011-10-13 16:08 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T152144-60@post.gmane.org>
On 13.10.2011 15:58, arQon wrote:
> Andreas Ericsson<ae<at> op5.se> writes:
>> there's no reason to refuse the branch change.
>> Partly because nothing will be lost
>
> Actually, this isn't true either, because of the second bug: doing a revert
> in branchA causes the changes in branchB to be lost. This can't possibly be
> the intended behavior: again, it completely violates the integrity of branches
> by allowing changes on one branch to impact a different branch.
I assume you mean revert through 'git checkout' and not through 'git
revert'. Git uses a different philosphy. It works best with small
commits and commits done often. It assumes that when you switch
branches, you don't switch your brain as well and still know for what
purpose you changed tr_font.cpp (and even if you forget you always can
check with git diff).
It also reminds you that tr_font.cpp is changed when you switch branches
(remember the "M tr_font.cpp" printed when you switched to another branch).
It assumes that when you use 'git checkout --' to wipe out changed files
without committing them anywhere(!) that you have thought about it the
same way you have thought about before deleting or overwriting any file
in the file system. The same way you have thought about before deleting
or overwriting an uncommitted file in svn.
What you term integrity of the branch is a model you made of the
workings of svn that you now try to pin onto a different model.
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Alexey Shumkin @ 2011-10-13 16:17 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T171530-970@post.gmane.org>
> Lucky you. :P The most likely reason for me is, I'm working on
> something and I get interrupted and have to switch. Since the code
> may well not even compile at this point, the last thing I want to do
> is commit it.
"git stash" helps here
With Git you can/have_to/must change your SVN-based habits.
DO NOT BE AFRAID OF FREQUENT COMMITS!
There are local until you push them.
>git's ability for that commit to be local is half the
> reason I'm trying to switch to it.
You always have a chance to modify/reedit you commits
see "git commit --amend" and "git rebase [-i]"
I'm telling you it as an ex-SVN user.
>(I'm not particularly keen on
> having to commit broken code to even a local repo, but that's still a
> hell of a lot better than having it pushed upstream as well).
Again, do not be afraid to commit your changes. Be afraid of losing
your changes. Git makes everything (as other discussion participants
already described) to keep your changes within workflow when you
switch between branches often.
Read some books which are describe Git's usual (and effective) workflow,
ProGit - http://progit.org/book/
Version Contol by Example (there is a chapter about Git) -
http://git-scm.com/course/svn.html
Hope, you'll feel the power of Git ))
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: arQon @ 2011-10-13 16:17 UTC (permalink / raw)
To: git
In-Reply-To: <20111013144450.GA2856@victor.terreactive.ch>
Victor Engmark <victor.engmark <at> terreactive.ch> writes:
> 1. `checkout master` and commit the fix there, then shift back and
> continue working
I absolutely agree. And it's far more common than any of us would like.
My point is, you *can't* do this in git without first staging your current branch
via either commit or stash, or you risk changes bleeding between the branches
and/or work being lost irretrievably. This is not something that you would
expect, and as you say:
> The second most important thing a VCS should do is not destroy any of your
uncommitted work unless you tell it to
... which is exactly what git does, and why I have a problem with it.
But the response here is uniformly "that's just how git is", so obviously it's
something you learn to become aware of over time, and avoid. It's not going to
get "fixed", because people who are used to git don't see it as a bug, so I just
have to decide whether I can live with it or not.
^ permalink raw reply
* Re: [BUG] git checkout <branch> allowed with uncommitted changes
From: Holger Hellmuth @ 2011-10-13 16:32 UTC (permalink / raw)
To: arQon; +Cc: git
In-Reply-To: <loom.20111013T171530-970@post.gmane.org>
On 13.10.2011 17:53, arQon wrote:
>> git st
> # On branch foo
> # Changes not staged for commit:
> # (use "git add<file>..." to update what will be committed)
> # (use "git checkout --<file>..." to discard changes in working directory)
> #
> # modified: file1.txt
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> What makes this really interesting though is this: I tried to switch to
> master to see if that gave the same warning, and NOW, I get the correct
> error.
>
>> git co master
> error: Your local changes to the following files would be overwritten by
> checkout:
> file1.txt
> Please, commit your changes or stash them before you can switch branches.
> Aborting
At the end of your example (in a previous email) you were on branch
master, now in the beginning you are on foo. So you at least changed
branch again inbetween. maybe you also committed something? Check out
git log or gitk
I tried your example and I can checkout master and foo again and again
and I never see the error message.
> Lucky you. :P The most likely reason for me is, I'm working on something
> and I get interrupted and have to switch. Since the code may well not even
> compile at this point, the last thing I want to do is commit it. git's
> ability for that commit to be local is half the reason I'm trying to switch
> to it. (I'm not particularly keen on having to commit broken code to even a
> local repo, but that's still a hell of a lot better than having it pushed
> upstream as well).
As Alexey already said, just commit and later amend. Or stash. Git
encourages you to commit small changes you can put a name to. You never
should delay a commit because it produces unworkable code. Instead have
a master branch (or branches) that always compiles and branches for the
unfinished stuff. Then it won't matter if some branch is only half working.
^ 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