* Re: [PATCH] run-command.c: Accept EACCES as command not found
From: Nguyen Thai Ngoc Duy @ 2011-11-23 12:04 UTC (permalink / raw)
To: Frans Klaver; +Cc: Junio C Hamano, git
In-Reply-To: <CAH6sp9N2ycsoU=is3BVanH33CowD+sMNmWq=Z1MsPJX=HGYY+g@mail.gmail.com>
On Wed, Nov 23, 2011 at 3:17 PM, Frans Klaver <fransklaver@gmail.com> wrote:
> If there are no objections, I'm going to cook up a patch that
>
> - Keeps the current behavior (bail on EACCES)
> - Adds a more helpful diagnostic message somewhat like libexplain's,
> but more terse and if possible with slightly more domain knowledge
If you print diagnostic messages with trace_printf() and friends (only
showed when GIT_TRACE variable is set), then there's no need for being
terse.
--
Duy
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Nguyen Thai Ngoc Duy @ 2011-11-23 12:02 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git
In-Reply-To: <CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com>
On Wed, Nov 23, 2011 at 3:28 PM, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
> Hello,
>
> A lot of time when I want to use reset for smth else than "--hard" I
> have to go and look the documentation.
May be related: http://thread.gmane.org/gmane.comp.version-control.git/170266
--
Duy
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-23 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vk46th5bz.fsf@alter.siamese.dyndns.org>
On Mon, Nov 21, 2011 at 10:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> In the medium term, I think one reasonable way forward solving the "TODO
> that used to be tracked but now untracked and ignored" issue is to
> introduce "info/exclude-override" that comes between command line and
> in-tree patterns. The info/exclude file is designed as the fallback
> definition to be used when all other sources are too lax, and comes near
> the precedence stack; the "TODO" situation however calls for an override
> that is stronger than the in-tree patterns.
"info/precious" might be a better name
> In the longer term, we should carefully determine if we need "precious" in
> the first place. The last time this was brought up there were people who
> argued they are OK with having to remove the ignored file by hand when
> checking out another branch (i.e. we switch the semantics of "ignored" so
> that they are "not tracked but all precious").
>
> I think it matters in two cases.
>
> (1) If you change an untracked "cruft" file on branch A into a directory
> with tracked files in it on another branch B. If you are on branch A,
> have that "cruft" file (perhaps it is a build product after running
> "make"), and try to checkout branch B, such an updated "git checkout"
> will start erroring out telling you that "cruft" will be lost.
>
> (2) If you have a directory on branch A, underneath of which there are
> untracked "cruft" files (e.g. think "build/" directory that is full
> of "*.o" files and ".gitignore" to mark object files as ignored but
> is otherwise empty), and another branch B that has the same path as a
> file. If you are on branch A, have "cruft" files in that directory,
> and try to checkout branch B, such an updated "git checkout" will
> start erroring out telling you that "cruft" will be lost.
I think we should do this regardless precious being added or not.
> If people are OK with such a behaviour, we can do without "precious".
What about git-clean to remove ignored but not precious files?
> Otherwise we would need to update excluded() in dir.c to return tristate
> (ignored, precious or unspecified) instead of the current boolean (ignored
> or unspecified), examine and decide for each caller what they want to do
> to "precious" files.
Or do excluded() twice, the first time to check for precious files,
the second for all ignored rules. Callers are changed anyway, but this
way git-add for example will be untouched because it does not care
about precious stuff. Only unpack-trees and maybe git-clean are
changed.
--
Duy
^ permalink raw reply
* Re: git reset --merge documentation improvments
From: Philippe Vaucher @ 2011-11-23 11:39 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git
In-Reply-To: <4ECCB565.9020706@lyx.org>
>> "Updates the files in the working tree that are different between
>> <commit> and HEAD, but keeps those which are different between the
>> index and working tree, and finally resets the index."
>
> There is nothing to update as long as the index is not reset.
Well then I simply don't understand what --merge does. Is it like
--keep but instead of failing when a file-to-be-overwritten has
changes it simply ignores the overwriting and continues?
Philippe
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Philippe Vaucher @ 2011-11-23 11:32 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq4nxvusty.fsf@bauges.imag.fr>
>> Optional: a new mode would be introduced for consistency:
>> --worktree (or maybe --tree): only updates the worktree but not the index
>
> That would be an alias for "git checkout <rev> -- path", right?
Hum... yeah probably, what motivated me was that there's a way to
reset the index and not the worktree, but there's no way to reset the
worktree but not the index. I guess it's "checkout" as you pointed
out.
>> --keep could be removed in favor of an additional --safe flag
>
> If you are to change the option names, then you should also make the
> behavior safe by default:
>
> * "git reset --all" = "git reset --keep"
> * "git reset --all --force" = "git reset --hard"
Yes that's actually much better. Let's change my proposal to that.
Philippe
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-23 11:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vfwhhgzcb.fsf@alter.siamese.dyndns.org>
On Tue, Nov 22, 2011 at 12:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> It dated back to f8a9d42 (read-tree: further loosen "working file will
>> be lost" check. - 2006-12-04) when you introduced --exclude-per-directory
>> to read-tree, but not --exclude-from to explicitly add .git/info/exclude.
>
> That one together with 1127148 (Loosen "working file will be lost" check
> in Porcelain-ish, 2006-12-04) complets the picture. Thanks for digging
> this out.
>
>> I guess it's time to add "read-tree --exclude-from".
>
> Perhaps, also --exclude-standard to match?
Yep, will do.
--
Duy
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: Stefan Näwe @ 2011-11-23 11:24 UTC (permalink / raw)
To: David Aguilar; +Cc: dexen deVries, git@vger.kernel.org
In-Reply-To: <CAJDDKr78CV+eDrfSg4Tqp5W2N4MDTaqAcxiB5JrNpUyEn5vqAQ@mail.gmail.com>
Am 23.11.2011 12:20, schrieb David Aguilar:
> On Tue, Nov 22, 2011 at 7:19 AM, Stefan Näwe
> <stefan.naewe@atlas-elektronik.com> wrote:
>> Am 22.11.2011 11:24, schrieb David Aguilar:
>>>
>>> git-cola has this feature.
>>>>
>>>
>>> http://git-cola.github.com/
>>
>> Yeah, right. I totally forgot about git cola.
>>
>> But I guess there's no way of starting only the stash view like the 'DAG'
>> view, is there ?
>
> That's a good idea.
>
> https://github.com/git-cola/git-cola/commit/0b1bf59c0b4a455cc8a9149dcfcafb5bed3a19ab
>
> git cola stash
> git cola classic
> (and a few others)
> ...
Perfetto!
Stefan
--
----------------------------------------------------------------
/dev/random says: Thesaurus: ancient reptile with an excellent vocabulary.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: David Aguilar @ 2011-11-23 11:20 UTC (permalink / raw)
To: Stefan Näwe; +Cc: dexen deVries, git@vger.kernel.org
In-Reply-To: <4ECBBD72.40101@atlas-elektronik.com>
On Tue, Nov 22, 2011 at 7:19 AM, Stefan Näwe
<stefan.naewe@atlas-elektronik.com> wrote:
> Am 22.11.2011 11:24, schrieb David Aguilar:
>>
>> git-cola has this feature.
>>>
>>
>> http://git-cola.github.com/
>
> Yeah, right. I totally forgot about git cola.
>
> But I guess there's no way of starting only the stash view like the 'DAG'
> view, is there ?
That's a good idea.
https://github.com/git-cola/git-cola/commit/0b1bf59c0b4a455cc8a9149dcfcafb5bed3a19ab
git cola stash
git cola classic
(and a few others)
...
--
David
^ permalink raw reply
* Re: [PATCH] Fix revert --abort on Windows
From: Johannes Sixt @ 2011-11-23 10:21 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111123100452.GA30629@elie.hsd1.il.comcast.net>
Am 11/23/2011 11:04, schrieb Jonathan Nieder:
> ... "git reset --merge <commit>" renames the
> .git/sequencer directory as a secondary effect --- after moving to
> <commit>, or so the logic goes, it is unlikely but possible that the
> caller of git reset wants to continue the series of cherry-picks that
> was in progress, so git renames the sequencer state to
> .git/sequencer-old to be helpful while allowing the cherry-pick to be
> resumed if the caller did not want to end the sequence after all.
> ...
> By the way, as the length of [this paragraph] might
> have hinted, I am not convinced that allowing "git reset --hard" as an
> escape route from a cherry-pick sequence was very sensible. It
> _would_ be nice to have a command to return to a known state,
> discarding progress in all pending multiple-command guided workflows
> (am, rebase, bisect), but git reset is not that command.
IMO, it doesn't make sense that git-reset aborts a cherry-pick sequence:
When I messed up a difficult conflict in the middle of a cherry-pick
sequence, it might be useful to be able to 'git reset --hard && git
cherry-pick that-one-commit' to restart the conflict resolution.
(But does a single-commit cherry-pick during a multi-commit cherry-pick
work to begin with?)
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix revert --abort on Windows
From: Jonathan Nieder @ 2011-11-23 10:04 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <4ECCB3A2.5030102@viscovery.net>
Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> On Windows, it is not possible to rename or remove a directory that has
> open files. 'revert --abort' renamed .git/sequencer when it still had
> .git/sequencer/head open. Close the file as early as possible to allow
> the rename operation on Windows.
Nice catch.
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Speaking of which, it doesn't make a lot of sense for "git revert
--abort" to be leaving a .git/sequencer-old directory around. How
about this on top?
-- >8 --
Subject: revert --abort: do not leave behind useless sequencer-old directory
The "git cherry-pick --abort" command currently renames the
.git/sequencer directory to .git/sequencer-old instead of removing it
on success due to an accident. cherry-pick --abort is designed to
work in three steps:
1) find which commit to roll back to
2) call "git reset --merge <commit>" to move to that commit
3) remove the .git/sequencer directory
But the careless author forgot step 3 entirely. The only reason the
command worked anyway is that "git reset --merge <commit>" renames the
.git/sequencer directory as a secondary effect --- after moving to
<commit>, or so the logic goes, it is unlikely but possible that the
caller of git reset wants to continue the series of cherry-picks that
was in progress, so git renames the sequencer state to
.git/sequencer-old to be helpful while allowing the cherry-pick to be
resumed if the caller did not want to end the sequence after all.
By running "git cherry-pick --abort", the operator has clearly
indicated that she is not planning to continue cherry-picking. Remove
the (renamed) .git/sequencer directory as intended all along.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
By the way, as the length of the second-to-last paragraph above might
have hinted, I am not convinced that allowing "git reset --hard" as an
escape route from a cherry-pick sequence was very sensible. It
_would_ be nice to have a command to return to a known state,
discarding progress in all pending multiple-command guided workflows
(am, rebase, bisect), but git reset is not that command.
builtin/revert.c | 1 +
t/t7106-reset-sequence.sh | 8 ++++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 5dedb51c..818b4abb 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -942,6 +942,7 @@ static int sequencer_rollback(struct replay_opts *opts)
}
if (reset_for_rollback(sha1))
goto fail;
+ remove_sequencer_state(1);
strbuf_release(&buf);
return 0;
fail:
diff --git a/t/t7106-reset-sequence.sh b/t/t7106-reset-sequence.sh
index 3f86e8c5..83f7ea59 100755
--- a/t/t7106-reset-sequence.sh
+++ b/t/t7106-reset-sequence.sh
@@ -41,4 +41,12 @@ test_expect_success 'reset --hard cleans up sequencer state, providing one-level
test_path_is_missing .git/sequencer-old
'
+test_expect_success 'cherry-pick --abort does not leave sequencer-old dir' '
+ pristine_detach initial &&
+ test_must_fail git cherry-pick base..anotherpick &&
+ git cherry-pick --abort &&
+ test_path_is_missing .git/sequencer &&
+ test_path_is_missing .git/sequencer-old
+'
+
test_done
--
1.7.8.rc3
^ permalink raw reply related
* Re: Possible bug with branch names and case sensitivity
From: Michael Haggerty @ 2011-11-23 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Gerd Knops, git
In-Reply-To: <7vwrasdp3t.fsf@alter.siamese.dyndns.org>
On 11/22/2011 06:49 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> Currently git handles references names case-sensitively and allows
>> multiple reference names that differ only in case.
>
> We do the same for in-tree paths, by the way. Ultimately, I think the
> sane thing to do is to appeal to the user's common sense. [...common
> sense aka "if it hurts don't do it" omitted...]
>
> I think refnames have exactly the same issue. In theory, you could have
> "Master" and "master" branches, and nothing stops you from trying to do
> so, but in practice, if it is not useful for you and your project, and
> if it is equally fine to use some other name instead of "Master" for the
> purpose of you and your project, then there is no strong reason for doing
> so, unless you are trying to irritate users on case folding platforms.
I agree.
But git could nevertheless help users (1) by providing config settings
or hook scripts or something that could be configured in a repository to
prevent case-conflicts from entering the project history; (2) by
emitting an error when such a conflict arises rather than getting so
confused.
Note that Unicode encoding differences can cause very similar problems
(even assuming utf8, there can be multiple ways to encode the same
string) and should maybe be addressed similarly.
By the way, I'm not volunteering for this project; case-sensitive
ASCII's good enough for me :-)
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* git fetch overwriting local tags
From: Uwe Kleine-König @ 2011-11-23 9:08 UTC (permalink / raw)
To: git; +Cc: John Kacur
Hello,
John and I wondered about git fetch overwriting local tags. I was sure
enough to claim that git fetch won't overwrite local tags with remote
tags having the same name. But after John pointed me to
http://www.pythian.com/news/9067/on-the-perils-of-importing-remote-tags-in-git/
I tested that (using Debian's 1.7.7.3) and really, git does overwrite
local tags.
Here is my test script:
mkdir a
cd a
echo some content > some_file
git init
git add some_file
git commit -m 'some commit log'
git tag some_tag
cd ..
mkdir b
cd b
echo some different content > another_file
git init
git add another_file
git commit -m 'another commit log'
git tag some_tag
git fetch --tags ../a
After that I have:
git log -1 --oneline some_tag
c4ad89a some commit log
so b's tag was overwritten.
Is this intended?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [ANN] SubGit Early Access Program Build #789
From: Andreas Ericsson @ 2011-11-23 9:03 UTC (permalink / raw)
To: Semen Vadishev; +Cc: jgit-dev, EGit developer discussion, Git Mailing List
In-Reply-To: <4ECBF4EF.7070705@tmatesoft.com>
On 11/22/2011 08:15 PM, Semen Vadishev wrote:
> Hello All,
>
> Let me introduce our new project: SubGit (http://subgit.com/).
>
> SubGit is a tool for smooth migration from Subversion to Git. As well as
> from Git to Subversion. Without git-svn insanity.
>
> It works like this:
>
> - Install SubGit into your repository on the server side
>
> - Let initial translation complete (time depends on the size of repository)
>
> - SubGit installs hooks into repository, so it translates every svn
> revision and git commit
>
> - Committers may now use either Git or Subversion (or both) with the
> tools of their choice
>
How does it handle merges?
--
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: git reset --merge documentation improvments
From: Vincent van Ravesteijn @ 2011-11-23 8:57 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git
In-Reply-To: <CAGK7Mr59bN8rjhLHAK0Vq=bOBBHG=N02CgGe-np=OBdTyS+rsA@mail.gmail.com>
Op 23-11-2011 9:31, Philippe Vaucher schreef:
> Hello,
>
> The current documentation for --merge is:
>
> "Resets the index [1] and updates the files in the working tree that
> are different between<commit> and HEAD, but keeps those which are
> different between the index [2] and working tree"
>
> I think this is confusing, because [1] is the *after-reset* index and
> [2] is the *before-reset* index.
You mean that you read that the *after-reset* index is reset ? They both
refer to the *before-reset* index.
> If you fail to realise this it looks
> like this "resets index (so index is empty) and then updates worktree
> but skip files staged from index" --> "but there's nothing staged, the
> index was reset!"
The misunderstanding comes from the added "then".
>
> I think a better sentence would be:
>
> "Updates the files in the working tree that are different between
> <commit> and HEAD, but keeps those which are different between the
> index and working tree, and finally resets the index."
There is nothing to update as long as the index is not reset.
Vincent
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Michael Haggerty @ 2011-11-23 8:54 UTC (permalink / raw)
To: Jay Soffian; +Cc: Gerd Knops, git, Junio C Hamano
In-Reply-To: <CAG+J_DxREbykWggrD49L7qvR9M36wKL7+_kOYbvcWmLBCF2Gog@mail.gmail.com>
On 11/22/2011 06:31 PM, Jay Soffian wrote:
> I wonder what the downside would be of always using packed refs on
> case-insenstive file systems. This would seem analogous to how git no
> longer uses symlinks.
The theoretical downside is that when the total number of packed refs is
very large, it is more expensive to access or change a single ref if it
is packed than if it is loose (because the whole packed refs file has to
be read, parsed, then rewritten, and thus scales like O(N)). OTOH the
number of references must be quite large before loose references win,
because the constant factor for loose references is much larger than
that for packed references. I also believe that there is still scope
for optimizing the handling of packed references to make them yet faster
and perhaps even improve their scaling.
But I think that a lot of code would have to change to make this happen.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH] Fix revert --abort on Windows
From: Johannes Sixt @ 2011-11-23 8:49 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord, Jay Soffian
In-Reply-To: <20111123012721.GA14217@elie.hsd1.il.comcast.net>
From: Johannes Sixt <j6t@kdbg.org>
On Windows, it is not possible to rename or remove a directory that has
open files. 'revert --abort' renamed .git/sequencer when it still had
.git/sequencer/head open. Close the file as early as possible to allow
the rename operation on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I guess it's too late to squash this in. ;)
-- Hannes
builtin/revert.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index 0c61668..5dedb51 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -931,8 +931,10 @@ static int sequencer_rollback(struct replay_opts *opts)
if (strbuf_getline(&buf, f, '\n')) {
error(_("cannot read %s: %s"), filename, ferror(f) ?
strerror(errno) : _("unexpected end of file"));
+ fclose(f);
goto fail;
}
+ fclose(f);
if (get_sha1_hex(buf.buf, sha1) || buf.buf[40] != '\0') {
error(_("stored pre-cherry-pick HEAD file '%s' is corrupt"),
filename);
@@ -941,11 +943,9 @@ static int sequencer_rollback(struct replay_opts *opts)
if (reset_for_rollback(sha1))
goto fail;
strbuf_release(&buf);
- fclose(f);
return 0;
fail:
strbuf_release(&buf);
- fclose(f);
return -1;
}
--
1.7.8.rc3.1164.gba869.dirty
^ permalink raw reply related
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Matthieu Moy @ 2011-11-23 8:49 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git
In-Reply-To: <CAGK7Mr4GZq5eXn4OB+B0ZborX-OVoXiWU8Lo1XM5LRZDuRe1YA@mail.gmail.com>
Philippe Vaucher <philippe.vaucher@gmail.com> writes:
> A lot of time when I want to use reset for smth else than "--hard" I
> have to go and look the documentation.
I have to agree with this, I took a lot of time to understand/memorize
the meaning of reset options.
> Optional: a new mode would be introduced for consistency:
> --worktree (or maybe --tree): only updates the worktree but not the index
That would be an alias for "git checkout <rev> -- path", right?
I don't really like this "there is more than one way to do it" in Git's
command-line, I think we should think very carefully before introducing
yet another instance of it.
> --keep could be removed in favor of an additional --safe flag
If you are to change the option names, then you should also make the
behavior safe by default:
* "git reset --all" = "git reset --keep"
* "git reset --all --force" = "git reset --hard"
With the current terminology, --hard has the advantage that it makes it
realatively clear how dangerous it is. Still, I've seen users losing
data because they did a "git reset --hard" with uncommited changes. Git
is safe by default most of the time, and "git reset --hard" is one
unfortunate exception (because it was there before --keep, people are
more used to it).
"git reset --all" would make it worse, because the option name is less
scary, people would be less reluctant to use it, and would get more
chance to lose data.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* git reset --merge documentation improvments
From: Philippe Vaucher @ 2011-11-23 8:31 UTC (permalink / raw)
To: git
Hello,
The current documentation for --merge is:
"Resets the index [1] and updates the files in the working tree that
are different between <commit> and HEAD, but keeps those which are
different between the index [2] and working tree"
I think this is confusing, because [1] is the *after-reset* index and
[2] is the *before-reset* index. If you fail to realise this it looks
like this "resets index (so index is empty) and then updates worktree
but skip files staged from index" --> "but there's nothing staged, the
index was reset!"
I think a better sentence would be:
"Updates the files in the working tree that are different between
<commit> and HEAD, but keeps those which are different between the
index and working tree, and finally resets the index."
Or something along those lines.
Philippe
^ permalink raw reply
* Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Philippe Vaucher @ 2011-11-23 8:28 UTC (permalink / raw)
To: git
Hello,
A lot of time when I want to use reset for smth else than "--hard" I
have to go and look the documentation.
I think the modes could be improved by creating new aliases like this:
Optional: a new mode would be introduced for consistency:
--worktree (or maybe --tree): only updates the worktree but not the index
Then the existing mode could be aliased like this:
--mixed would be aliased as --index
--hard would be aliased as --all
--soft could be aliased as --no-changes
Additionally:
--merge could be removed in favor of an additional --preserve-staged flag
--keep could be removed in favor of an additional --safe flag
So if I recap my ideas:
"I want to discard my changes" --> git reset --all HEAD^
"I want to discard the last commit" --> git reset --index HEAD^
"I want to discard the last commit, but let's be safe in case I forgot
about a modified file" --> git reset --all --safe HEAD^
"I want to discard the last commit, keep my current staged changes"
--> git reset --all --preserve-staged HEAD^
Philippe
^ permalink raw reply
* Re: [PATCH] run-command.c: Accept EACCES as command not found
From: Frans Klaver @ 2011-11-23 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <CAH6sp9MxbDhQ3RiA6jO1fswAZX3R6C2fv0gzJdpGp432ovWsjQ@mail.gmail.com>
On Tue, Nov 22, 2011 at 10:31 AM, Frans Klaver <fransklaver@gmail.com> wrote:
> If git is going to do some diagnostics on why the execvp returned
> EACCES, it can still give a few hints. Most of the more likely options
> are then ruled out.
If there are no objections, I'm going to cook up a patch that
- Keeps the current behavior (bail on EACCES)
- Adds a more helpful diagnostic message somewhat like libexplain's,
but more terse and if possible with slightly more domain knowledge
- Takes into account the notes made following
http://article.gmane.org/gmane.comp.version-control.git/171838
Frans
^ permalink raw reply
* [PATCH] Fix https interactive authentication problem
From: Steinmann Ruedi @ 2011-11-23 7:58 UTC (permalink / raw)
To: git@vger.kernel.org, gitster@pobox.com
>From 986e29085ee2215a3e0a412ee7874dc2d0ef36be Mon Sep 17 00:00:00 2001
From: Ruedi Steinmann <ruediste@student.ethz.ch>
Date: Wed, 23 Nov 2011 08:41:52 +0100
Subject: [PATCH] Fix https interactive authentication problem
Cloning a repository over https works fine when the username/password is
given in the URL. But if it is queried interactively, an error occurs(see below).
I found that the username/password is not set when a connection is reused.
With this patch, the username/password is set whenever a connection is reused.
Sample output showing the error:
git clone https://n.ethz.ch/student/...
Cloning into ...
Username:
Password:
error: Unable to get pack file https://n.ethz.ch/student/.../objects/pack/pack-1ced2ebff0c9fc1f07e0c7cc9dd3fc75f6ac6962.pack
The requested URL returned error: 401
...
error: Fetch failed.
Signed-off-by: Ruedi Steinmann <ruediste@student.ethz.ch>
---
http.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index e6c7597..c7b3558 100644
--- a/http.c
+++ b/http.c
@@ -550,7 +550,10 @@ struct active_request_slot *get_active_slot(void)
curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, NULL);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 0);
curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
-
+
+ // set username and password if already set
+ init_curl_http_auth(slot->curl);
+
return slot;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH] builtin-reset: Documentation update
From: vfr @ 2011-11-23 6:44 UTC (permalink / raw)
To: git; +Cc: gitster, Vincent van Ravesteijn
From: Vincent van Ravesteijn <vfr@lyx.org>
The second mode of 'git reset' is defined by the --patch
option, while the third mode is defined by the <mode> option.
Hence, these options are mandatory in the description of the
individual modes.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
Documentation/git-reset.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index b2832fc..b674866 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -9,8 +9,8 @@ SYNOPSIS
--------
[verse]
'git reset' [-q] [<commit>] [--] <paths>...
-'git reset' [--patch|-p] [<commit>] [--] [<paths>...]
-'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]
+'git reset' (--patch | -p) [<commit>] [--] [<paths>...]
+'git reset' (--soft | --mixed | --hard | --merge | --keep) [-q] [<commit>]
DESCRIPTION
-----------
@@ -34,7 +34,7 @@ Alternatively, using linkgit:git-checkout[1] and specifying a commit, you
can copy the contents of a path out of a commit to the index and to the
working tree in one go.
-'git reset' --patch|-p [<commit>] [--] [<paths>...]::
+'git reset' (--patch | -p) [<commit>] [--] [<paths>...]::
Interactively select hunks in the difference between the index
and <commit> (defaults to HEAD). The chosen hunks are applied
in reverse to the index.
@@ -43,7 +43,7 @@ This means that `git reset -p` is the opposite of `git add -p`, i.e.
you can use it to selectively reset hunks. See the ``Interactive Mode''
section of linkgit:git-add[1] to learn how to operate the `\--patch` mode.
-'git reset' [--<mode>] [<commit>]::
+'git reset' --<mode> [<commit>]::
This form resets the current branch head to <commit> and
possibly updates the index (resetting it to the tree of <commit>) and
the working tree depending on <mode>, which
--
1.7.8-rc3
^ permalink raw reply related
* [PATCH] builtin-branch: Fix crash on invalid use of --force
From: vfr @ 2011-11-23 6:31 UTC (permalink / raw)
To: git; +Cc: gitster, Vincent van Ravesteijn
From: Vincent van Ravesteijn <vfr@lyx.org>
The option --force should not put us in 'create branch' mode. The
fact that this option is only valid in 'create branch' mode is
already caught by the the next 'if' in which we assure that we
are in the correct mode.
Without this patch, we end up calling create_branch without any
arguments. This means that argv[0] makes not much sense and
that we will finally crash because the branch name is a NULL
pointer. Hence the added safety check that we should not try
to create a branch without a name.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
builtin/branch.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 51ca6a0..55cad76 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -705,7 +705,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, builtin_branch_usage,
0);
- if (!delete && !rename && !force_create && argc == 0)
+ if (!delete && !rename && argc == 0)
list = 1;
if (!!delete + !!rename + !!force_create + !!list > 1)
@@ -726,7 +726,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
rename_branch(argv[0], argv[1], rename > 1);
else
usage_with_options(builtin_branch_usage, options);
- } else if (argc <= 2) {
+ } else if (argc > 0 && argc <= 2) {
if (kinds != REF_LOCAL_BRANCH)
die(_("-a and -r options to 'git branch' do not make sense with a branch name"));
create_branch(head, argv[0], (argc == 2) ? argv[1] : head,
--
1.7.8-rc3
^ permalink raw reply related
* Re: git not resuming push
From: Junio C Hamano @ 2011-11-23 6:24 UTC (permalink / raw)
To: Paul Brossier; +Cc: git
In-Reply-To: <20111123050220.GA9127@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 22, 2011 at 08:58:56PM -0700, Paul Brossier wrote:
>
>> If the connection fails after uploading part of the data, it seems I
>> need to start over from zero again. Is there a way to resume the upload
>> instead?
>
> No, there isn't a way to resume just using push.
>
> If you have shell access on the server, one workaround you can do is to
> create a bundle with the commits in question, upload it via some
> resumable protocol (like sftp, http, rsync, etc), possibly taking many
> attempts, and then fetch the result on the server side from the bundle
> into the repository.
>
> See "git help bundle" for some examples.
Another possibility, if it is the connection between you and the other
side that is the problem, is to chunk your push in smaller pieces. That
is, if you are trying to push out v3.0, you first push only to v1.0, then
to v2.0, and then finally to v3.0.
Peff, by the way, wouldn't this request reminds of us of a scenario we
discussed recently, which I said I would imagine would be common while you
dismissed as not likely to be common?
^ permalink raw reply
* Re: git not resuming push
From: Jeff King @ 2011-11-23 5:02 UTC (permalink / raw)
To: Paul Brossier; +Cc: git
In-Reply-To: <4ECC6F80.6010907@piem.org>
On Tue, Nov 22, 2011 at 08:58:56PM -0700, Paul Brossier wrote:
> If the connection fails after uploading part of the data, it seems I
> need to start over from zero again. Is there a way to resume the upload
> instead?
No, there isn't a way to resume just using push.
If you have shell access on the server, one workaround you can do is to
create a bundle with the commits in question, upload it via some
resumable protocol (like sftp, http, rsync, etc), possibly taking many
attempts, and then fetch the result on the server side from the bundle
into the repository.
See "git help bundle" for some examples.
-Peff
^ 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