* Re: Usability question
From: Matthieu Moy @ 2009-09-17 13:09 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Rob Barrett, git
In-Reply-To: <20090917121328.GA21837@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> I tend to aggree, but what about 'git rebase --abort' vs. 'git rebase
> --continue'? IMHO they are also doing something totally different.
If I were to rewrite it, I'd call them "git rebase abort" without
dashes. Not sure renaming them to subcommands is worth it though.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 2/2] gitk: Fix the geometry when restoring from zoomed state
From: Alexey Borzenkov @ 2009-09-17 13:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Pat Thoyts, git
In-Reply-To: <19122.10359.725107.949551@cargo.ozlabs.ibm.com>
On Thu, Sep 17, 2009 at 4:15 PM, Paul Mackerras <paulus@samba.org> wrote:
>> The patch to handle the geometry of a restored gitk by Alexy Borzenkov
>> causes the position of the columns to creep each time the application
>> is restarted. This patch addresses this by remembering the application
>> geometry for the normal state and saving that regardless of the actual
>> state when the application is closed.
>
> So this patch replaces Alexey's patch, then? The context in your patch
> doesn't match the changes made in Alexey's patch AFAICS.
Yes. Pat's patch replaces my patch.
^ permalink raw reply
* Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
From: Christian Couder @ 2009-09-17 13:25 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Christian Couder, git, Johannes Schindelin,
Stephan Beyer, Daniel Barkalow, Jakub Narebski, Linus Torvalds
In-Reply-To: <4AB23410.6080508@viscovery.net>
On Thu, Sep 17, 2009 at 3:05 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Christian Couder schrieb:
>> On Thu, Sep 17, 2009 at 9:24 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Junio C Hamano schrieb:
>>>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>> $ git stash
>>> $ git reset --hard $target
>>> $ git stash pop
>>>
>>>> I have _no_ idea what the intended use-case of --merge-safe is, and that
>>>> was why I asked Christian for clarification in the previous round. The
>>>> answer was still not clear enough so I pointed out --merge-safe could be
>>>> still doing a wrong thing even in _his_ use-case.
>>> Reading Christian in 200909170554.49416.chriscool@tuxfamily.org, I think
>>> this *is* his use-case? Christian?
>>
>> Yes, I agree, it can be used instead of git stash.
>
> It "can"? Do you say that you intend --merge-safe for something else in
> addition to the above stash + reset --hard + stash pop sequence? What?
As I said to Junio, another "use case" is to enable more commands (like
an improved cherry-pick) to be used with a dirty work tree or index.
>> By the way Linus, in his
>> patch that added the --merge option, said that --merge could be used like
>> that.
>
> But that use-case has one important difference: You can't use stash right
> before the reset:
>
> # work tree is dirty
> $ git pull $there $topic # assume we have conflicts
>
> # investigate result ...
> # oh no, that's crap, scratch it
>
> $ git stash what? conflicted changes?
> $ git reset what? --hard would remove my dirty state, too
>
> You are screwed. 'git reset --merge' comes to rescue.
>
> I'm pretty sure you don't mean --merge-safe to provide extra safety in
> *this* use-case,
You are right, I don't think it is usefull in this use case.
> but that you have a very different use-case in mind.
I don't have other use cases I didn't already talked about in mind.
Best regards,
Christian.
^ permalink raw reply
* Re: Usability question
From: Daniele Segato @ 2009-09-17 13:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Rob Barrett, git
In-Reply-To: <vpqy6odhn0d.fsf@bauges.imag.fr>
On Thu, Sep 17, 2009 at 12:01 PM, Rob Barrett <barrettboy@gmail.com> wrote:
> When starting with git people almost always ask some variant of "how
> do I know whether this option should be prefixed with dashes or not?"
> i.e. git reset --hard vs. git stash save --patch, which coupled with
> other path, sha and treeish args make things a bit more confusing.
> And people stop asking the question after they get used to git - but
> that's not the same as being usable.
without speaking of usability I'll tell them to use autocompletion to
see which command / options they have until
they get used to them
regards,
Daniele
^ permalink raw reply
* Re: [PATCH 04/15] Set _O_BINARY as default fmode for both MinGW and MSVC
From: Johannes Sixt @ 2009-09-17 13:30 UTC (permalink / raw)
To: Alexey Borzenkov
Cc: Marius Storm-Olsen, git, Johannes.Schindelin, msysgit, gitster,
j6t, lznuaa, raa.lkml, Marius Storm-Olsen
In-Reply-To: <e2480c70909170602l6afc9842v7be2b91fde9ad498@mail.gmail.com>
[for the archives: this is about intermittent failures of t3903-stash.sh
with MinGW git]
Alexey Borzenkov schrieb:
> "after finding i_tree and i_commit" is immediately before calculating
> w_tree. As you can see, "before git read-tree" is off by a second. I
> think it's just a bug in msys, cp -p doesn't preserve mtime exactly.
> :-/
Ah, now I recall everything: git-stash.sh does "cp -p", and from the times
where git-commit was still a shell script I know that this does not always
preserve the timestamp correctly. Since this is a bug attributable to MSYS
(and not MinGW git), I was satisfied by simply inserting 'sleep 1' in the
test case to avoid the racily-clean situation. (Although today, I would
modify the content to have a different size.)
-- Hannes
^ permalink raw reply
* [ANNOUNCE] codeBeamer 5.4, ALM on top of Git
From: Intland Software @ 2009-09-17 13:24 UTC (permalink / raw)
To: git
If you're using Git, and you need an issue tracker, wiki, doc
management, project management that tightly integrates with your
favourite git and somewhat resembles of GitHub-behind-a-firewall, then
you might be interested in this. If not, then we apologize.
codeBeamer 5.4 is the latest and greatest version of our collaborative
Application Lifecycle Management software
(http://www.intland.com/products/cb/overview.html).
Links:
* Product homepage: http://www.intland.com/products/cb/overview.html
* Download (no expiration!):
http://www.intland.com/products/download.html#download
* Hosted version: http://www.intland.com/products/download.html#trial
^ permalink raw reply
* Re: git workflow for fully distributed mini-teams
From: Rustom Mody @ 2009-09-17 13:52 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <f46c52560909170538q4d316d00jcccad8ec9f563574@mail.gmail.com>
On Thu, Sep 17, 2009 at 6:08 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Thu, Sep 17, 2009 at 12:58 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> I think the most important thing would be that you send bundles around,
>> not patches, so that you all can work with and talk about unique object names.
>>
>> -- Hannes
I started looking at git bundle and find things like master\~10.
Whats the backslash doing?
Tried running git bundle create with and without the backslash -- it
produced the same bundle.
Looked up tilde-expansion in bash and I gather bash does things to the
~ only on beginning of words whereas as far as I can see git uses ~
only at the end of words like master.
What am I missing?
^ permalink raw reply
* Re: Behavior of 'git add \*.txt': bug or feature?
From: Clemens Buchacher @ 2009-09-17 14:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vbplazl7s.fsf@alter.siamese.dyndns.org>
On Wed, Sep 16, 2009 at 01:30:15PM -0700, Junio C Hamano wrote:
> I strongly suspect that it comes from the fact that we have two
> definitions and three implementations of pathspec-aware tree traversal.
> One family is unaware of shell-glob wildcards (they only do leading
> directory path match) while the other know both leading directory path and
> shell-glob.
We had a discussion about this in January:
Subject: Re: [PATCH 3/3] implement pattern matching in ce_path_match
Message-ID: <7vljtd20m6.fsf@gitster.siamese.dyndns.org>
http://article.gmane.org/gmane.comp.version-control.git/105679
I was going to fix it, but motivation left me after the above discussion,
since I don't really care about this feature.
Clemens
^ permalink raw reply
* Re: git workflow for fully distributed mini-teams
From: Johannes Sixt @ 2009-09-17 14:47 UTC (permalink / raw)
To: Rustom Mody; +Cc: Git Mailing List
In-Reply-To: <f46c52560909170652t54f68c31hfbb8ae6472190ac1@mail.gmail.com>
[On this list, we reply to all, so that the Cc list remains]
Rustom Mody schrieb:
> I started looking at git bundle and find things like master\~10.
> Whats the backslash doing?
It's intended as markup for the pipeline that generates the documentation
from git-bundle.txt. Either the markup is incorrect, or there is a bug in
the pipeline, because I only see it in the generated HTML. Ignore it.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Update the usage bundle string.
From: Thiago Farina @ 2009-09-17 15:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AB1D364.1080701@viscovery.net>
On Thu, Sep 17, 2009 at 3:12 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Thiago Farina schrieb:
>> @@ -11,6 +11,12 @@
>>
>> static const char *bundle_usage="git bundle (create <bundle> <git rev-list args> | verify <bundle> | list-heads <bundle> [refname]... | unbundle <bundle> [refname]... )";
>
> Is this variable still used? Shouldn't it be removed?
Yeah it should be removed, I did this in the third email that I sent.
To send another revision of the patch I'm doing this:
$ git commit <filename> --amend
$ git format-patch -1 --subject-prefix "Patch vN"
But I'm not sure if this is the correct away to send another set of
changes of the same patch. Is right?
>
>> +static const char builtin_bundle_usage[] = "\
>> + git bundle create <file> <git-rev-list args>\n\
>> + git bundle verify <file>\n\
>> + git bundle list-heads <file> [refname...]\n\
>> + git bundle unbundle <file> [refname...]";
>
> You indent the usage text. Do other commands do that, too? If you resend,
> it may be worth using this style:
>
> static const char builtin_bundle_usage[] =
> "git bundle create <file> <git-rev-list args>\n"
> "git bundle verify <file>\n"
> ...
>
> i.e. not to use backslash-at-eol.
>
Sure, I will update it to use this style. There is another usage
string that uses backslash-at-eol, it is in builtin-pack-objecs.c .
Should I update this string too?
>> - if (argc < 3)
>> - usage(bundle_usage);
>> + if (argc < 3)
>> + usage(builtin_bundle_usage);
>
> This re-indentation is an accident, isn't it?
Was an accident, sorry about that. I configured my editor to use 2
spaces per indent, tab size 2 and expand tabs to spaces. Git uses 4
spaces per indent and tab size 4?
>
> -- Hannes
>
>
^ permalink raw reply
* Re: [PATCH] Update the usage bundle string.
From: Matthieu Moy @ 2009-09-17 16:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Thiago Farina, git
In-Reply-To: <4AB1D364.1080701@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Thiago Farina schrieb:
>
>> +static const char builtin_bundle_usage[] = "\
>> + git bundle create <file> <git-rev-list args>\n\
>> + git bundle verify <file>\n\
>> + git bundle list-heads <file> [refname...]\n\
>> + git bundle unbundle <file> [refname...]";
>
> You indent the usage text. Do other commands do that, too? If you resend,
> it may be worth using this style:
>
> static const char builtin_bundle_usage[] =
> "git bundle create <file> <git-rev-list args>\n"
> "git bundle verify <file>\n"
I like aligned usage strings, like:
$ git stash -h
Usage: git stash list [<options>]
or: git stash show [<stash>]
or: git stash drop [-q|--quiet] [<stash>]
or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: git stash branch <branchname> [<stash>]
or: git stash [save [-k|--keep-index] [-q|--quiet] [<message>]]
or: git stash clear
or
$ git branch -h |& head -n 4
usage: git branch [options] [-r | -a] [--merged | --no-merged]
or: git branch [options] [-l] [-f] <branchname> [<start-point>]
or: git branch [options] [-r] (-d | -D) <branchname>
or: git branch [options] (-m | -M) [<oldbranch>] <newbranch>
but Git isn't very consistant here:
$ git bisect -h |& head -n 6
Usage: git bisect [help|start|bad|good|skip|next|reset|visualize|replay|log|run]
git bisect help
print this long help message.
git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
reset bisect state and start bisection.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Update the usage bundle string.
From: Thiago Farina @ 2009-09-17 16:16 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Sixt, git
In-Reply-To: <vpqbpl9woac.fsf@bauges.imag.fr>
On Thu, Sep 17, 2009 at 1:04 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Thiago Farina schrieb:
>>
>>> +static const char builtin_bundle_usage[] = "\
>>> + git bundle create <file> <git-rev-list args>\n\
>>> + git bundle verify <file>\n\
>>> + git bundle list-heads <file> [refname...]\n\
>>> + git bundle unbundle <file> [refname...]";
>>
>> You indent the usage text. Do other commands do that, too? If you resend,
>> it may be worth using this style:
>>
>> static const char builtin_bundle_usage[] =
>> "git bundle create <file> <git-rev-list args>\n"
>> "git bundle verify <file>\n"
>
> I like aligned usage strings, like:
>
> $ git stash -h
> Usage: git stash list [<options>]
> or: git stash show [<stash>]
> or: git stash drop [-q|--quiet] [<stash>]
> or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
> or: git stash branch <branchname> [<stash>]
> or: git stash [save [-k|--keep-index] [-q|--quiet] [<message>]]
> or: git stash clear
>
> or
>
> $ git branch -h |& head -n 4
> usage: git branch [options] [-r | -a] [--merged | --no-merged]
> or: git branch [options] [-l] [-f] <branchname> [<start-point>]
> or: git branch [options] [-r] (-d | -D) <branchname>
> or: git branch [options] (-m | -M) [<oldbranch>] <newbranch>
>
I like and prefer this style too. I can use it in my patch, like:
$ git bundle -h
usage: git bundle create <file> <git-rev-list args>
or: git bundle verify <file>
or: git bundle list-heads <file> [refname...]
or: git bundle unbundle <file> [refname...]
instead of:
usage: git bundle create <file> <git-rev-list args>
git bundle verify <file>
git bundle list-heads <file> [refname...]
git bundle unbundle <file> [refname...]
> but Git isn't very consistant here:
>
> $ git bisect -h |& head -n 6
> Usage: git bisect [help|start|bad|good|skip|next|reset|visualize|replay|log|run]
>
> git bisect help
> print this long help message.
> git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
> reset bisect state and start bisection.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Bernd Jendrissek @ 2009-09-17 16:23 UTC (permalink / raw)
To: git
In-Reply-To: <fbs8es$1cd$1@sea.gmane.org>
Walter Bright <boost <at> digitalmars.com> writes:
> Sure, but I suggest that few projects reach this maxima. Case in point:
> ld, the gnu linker. It's terribly slow. To see how slow it is, compare
> it to optlink (the 15 years old one that comes with D for Windows). So I
> don't believe there is anything inherent about linking that should make
> ld so slow. There's some huge leverage possible in speeding up ld
> (spreading out that saved time among all the gnu developers).
http://en.wikipedia.org/wiki/Gold_(linker)
Note that gold is written in C++; the wikipedia quasi-stub article doesn't make
this clear. Normally that wouldn't be relevant, but in this branch of the
thread it is. Its C++-ness seems to be making an argument, but I don't know on
which side!
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #04; Wed, 16)
From: Nick Edelen @ 2009-09-17 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vm6kskd.fsf@alter.siamese.dyndns.org>
> * ne/rev-cache (2009-09-07) 7 commits
> . support for commit grafts, slight change to general mechanism
> . support for path name caching in rev-cache
> . full integration of rev-cache into git, completed test suite
> . administrative functions for rev-cache, start of integration into git
> . support for non-commit object caching in rev-cache
> . basic revision cache system, no integration or features
> . man page and technical discussion for rev-cache
>
> Replaced but I do not think this is ready for 'pu' yet.
Er, what direction would you suggest taking to bring this patchset up
to scratch? I've run several tests locally, and it seems to work as
intended, but I wouldn't assert that I've taken every possibility into
account. Should I submit some tests/benchmarks in more real-world
environments? I'm afraid that I'm not personally among the intended
audience for this, so I don't have a really solid idea of how this
might perform in the wild.
- Nick
^ permalink raw reply
* [PATCH v3] Update the usage bundle string.
From: Thiago Farina @ 2009-09-17 17:20 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Currently the usage bundle string is not well formatted.
Now it is formatted and the user can read the string much more easily.
Also makes the output more consistent with the other usage strings that use
usage_with_options to show the usage string.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-bundle.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-bundle.c b/builtin-bundle.c
index 9b58152..2006cc5 100644
--- a/builtin-bundle.c
+++ b/builtin-bundle.c
@@ -9,7 +9,11 @@
* bundle supporting "fetch", "pull", and "ls-remote".
*/
-static const char *bundle_usage="git bundle (create <bundle> <git rev-list args> | verify <bundle> | list-heads <bundle> [refname]... | unbundle <bundle> [refname]... )";
+static const char builtin_bundle_usage[] =
+ "git bundle create <file> <git-rev-list args>\n"
+ " or: git bundle verify <file>\n"
+ " or: git bundle list-heads <file> [refname...]\n"
+ " or: git bundle unbundle <file> [refname...]";
int cmd_bundle(int argc, const char **argv, const char *prefix)
{
@@ -20,7 +24,7 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
char buffer[PATH_MAX];
if (argc < 3)
- usage(bundle_usage);
+ usage(builtin_bundle_usage);
cmd = argv[1];
bundle_file = argv[2];
@@ -59,5 +63,5 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
return !!unbundle(&header, bundle_fd) ||
list_bundle_refs(&header, argc, argv);
} else
- usage(bundle_usage);
+ usage(builtin_bundle_usage);
}
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Gitk --all error when there are more than 797 refs in a repository
From: Murphy, John @ 2009-09-17 19:07 UTC (permalink / raw)
To: git
There is a error when running gitk --all when there are more than 797 refs in a repository.
We get an error message:
Error reading commits: fatal ambiguous argument '3': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions.
I believe issue is with this line of the code in proc parseviewrevs:
if {[catch {set ids [eval exec git rev-parse "$revs"]} err]}
When there are more than 797 refs the output of git rev-parse is too large to fit into the string, ids.
797 refs = 32,677 bytes.
798 refs = 32,718 bytes my guess is a little too close for comfort to 32,768 bytes.
As I was deleting refs locally the error message would change from '3' to any char [A-Z,0-9].
I am a novice tcl programmer but is seems like ids could be an array.
There are also many other areas in the code where git rev-parse is called and using array may also be necessary.
We were using:
git 1.6.3.2.314.ge3519
and then I upgraded to test if there was a change:
git 1.6.5.rc1.18.g401ce7
We are also using:
tcl 8.4.1
cygwin 1.5.25-7
Windows XP Pro SP3
^ permalink raw reply
* Re: [RFC 15/15] Tag GIT_VERSION when Git is built with MSVC
From: Johannes Sixt @ 2009-09-17 20:18 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: git, Johannes.Schindelin, msysgit, gitster, lznuaa, raa.lkml,
snaury
In-Reply-To: <894136433cc5b03a4b89a1f9c0e4f8a2704222fa.1253088099.git.mstormo@gmail.com>
On Mittwoch, 16. September 2009, Marius Storm-Olsen wrote:
> This may help us debug issues on Windows, as we now can build Git
> natively on Windows with both MinGW and MSVC.
>
> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
> ---
> I'm just throwing this one out there. If people think manipulating
> the version here, to ease debugging, I don't mind if this patch is
> squashed into patch 12.
> If people don't like it, just skip this path.
>
> Makefile | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index aa918eb..2c20922 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -878,6 +878,7 @@ ifneq (,$(findstring CYGWIN,$(uname_S)))
> UNRELIABLE_FSTAT = UnfortunatelyYes
> endif
> ifdef MSVC
> + GIT_VERSION := $(GIT_VERSION).MSVC
> pathsep = ;
> NO_PREAD = YesPlease
> NO_OPENSSL = YesPlease
I like it, but I would not squash it into patch 12.
-- Hannes
^ permalink raw reply
* Re: [PATCH 14/15] Add scripts to generate projects for other buildsystems (MSVC vcproj, QMake)
From: Johannes Sixt @ 2009-09-17 20:28 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: git, Johannes.Schindelin, msysgit, gitster, lznuaa, raa.lkml,
snaury
In-Reply-To: <aa80ad559c731ca73179956e34b2743d903fbbec.1253088099.git.mstormo@gmail.com>
On Mittwoch, 16. September 2009, Marius Storm-Olsen wrote:
> --- a/.gitignore
> +++ b/.gitignore
> @@ -179,3 +179,14 @@ configure
> tags
> TAGS
> cscope*
> +*.obj
> +*.lib
> +*.sln
> +*.suo
> +*.ncb
> +*.vcproj
> +*.user
> +*.idb
> +*.pdb
> +Debug/
> +Release/
If I understand correctly, then 'make MSVC=1' still produce *.o files, not
*.obj. But if the VC++ project is used, I expect that the *.obj, *.idb, and
*.pdb end up in Debug/ or Release/ directories. Then why do you need entries
for *.obj, *.idb, and *.pdb?
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
From: Junio C Hamano @ 2009-09-17 20:43 UTC (permalink / raw)
To: Johannes Sixt
Cc: Christian Couder, Christian Couder, git, Johannes Schindelin,
Stephan Beyer, Daniel Barkalow, Jakub Narebski, Linus Torvalds
In-Reply-To: <4AB23410.6080508@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Christian Couder schrieb:
>> On Thu, Sep 17, 2009 at 9:24 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Junio C Hamano schrieb:
>>>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>> $ git stash
>>> $ git reset --hard $target
>>> $ git stash pop
>>
> It "can"? Do you say that you intend --merge-safe for something else in
> addition to the above stash + reset --hard + stash pop sequence? What?
I think I am starting to understand. The use case in a larger picture
would look like
$ (edit/add/commit)+ to work towards something
... And you _finished_ that something.
$ (edit/add)+ to work towards something else that is wonderful
... Now you notice that all the commits for that earlier something
... are crap and you would want to discard them, while still keeping
... changes for "something else that is wonderful".
... Luckily, you haven't committed anything you would want to keep,
... and you can afford to reset the tip commits away.
$ git reset --keep-local-changes HEAD~7
... or howmanyever commits you want to discard.
The reset in this case is done purely to discard the crap, not to redo
them (you have something else you want to work on in your work tree and
index, and they are not fixups---if they were you wouldn't have resetted
but used "commit --amend" or "rebase -i").
It is more like switching branches but in this case you are switching to
your own branch immediately after rewinding that same branch.
In other words, as far as the index, the work tree and where HEAD will
point at are concerned, the new mode of reset works exactly like this:
$ (edit/add)+ to work towards something wonderful
... notice that the work does not belong to the current branch
... and you would want to switch to another branch while carrying
... your local changes.
$ git checkout another-branch
The only difference being that reset will stay on the same branch and
remove some commits from the tip of it, while checkout will leave the
original branch intact.
It makes sense that it has the same "safety" as "checkout" has when
switching branches; when you have modification in the index for a path,
and the path is different between switched-to commit and the current
commit, the command errors out with "cannot merge" (or a better message).
One drawback is that you can use this new mode of resetting only until you
make a commit that is part of the new "something else that is wonderful"
topic. After that "git reset" with this new option is not useful for this
workflow, and you would need to stash then rebase -i then unstash.
^ permalink raw reply
* Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
From: Daniel Barkalow @ 2009-09-17 21:04 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, Christian Couder, git, Johannes Schindelin,
Stephan Beyer, Jakub Narebski, Linus Torvalds
In-Reply-To: <c07716ae0909170525h21ab26f5y84b0fbce2192c69@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 914 bytes --]
On Thu, 17 Sep 2009, Christian Couder wrote:
> On Thu, Sep 17, 2009 at 7:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> > I'd like to see at least the following rows filled as well.
> >
> > X U A A --m-s ??? ??? ???
> > --merge ??? ??? ???
> > X U B A --m-s ??? ??? ???
> > --merge ??? ??? ???
> >
> >> In this table, A, B and C are some different states of a file.
> >
> > ... and X is "don't care", and U is "unmerged index".
>
> I will have a look, but it seems to me that --m-s and --merge
> behave the same in these cases.
It's still worth documenting, since it used to be entirely undocumented
(and probably not what it should have been), and also because you're
making it something reliable for the first time in this series.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH JGIT] Circular references shouldn't be created
From: Sohn, Matthias @ 2009-09-17 19:23 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git@vger.kernel.org
From: Matthias Sohn <matthias.sohn@sap.com>
Circular references shouldn't be created
Fix for bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=286743
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
---
.../tst/org/spearce/jgit/lib/RefTest.java | 9 +++++++++
.../src/org/spearce/jgit/lib/RefDatabase.java | 4 ++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefTest.java
index fabbe7e..ce6328b 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefTest.java
@@ -155,4 +155,13 @@ public void testOrigResolvedNamesSymRef() throws IOException {
assertEquals("refs/heads/master", ref.getName());
assertEquals("HEAD", ref.getOrigName());
}
+
+ public void testIllegalCircularRef() throws IOException {
+ try {
+ db.writeSymref("HEAD", "HEAD");
+ fail("creation of circular reference should fail");
+ } catch (IllegalArgumentException expected) {
+ // attempt to create circular reference should fail
+ }
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
index 09cb9bb..483b1d0 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
@@ -174,6 +174,10 @@ RefRename newRename(String fromRef, String toRef) throws IOException {
* @throws IOException
*/
void link(final String name, final String target) throws IOException {
+ if (name.equals(target))
+ throw new IllegalArgumentException(
+ "illegal circular reference : symref " + name
+ + " cannot refer to " + target);
final byte[] content = Constants.encode("ref: " + target + "\n");
lockAndWriteFile(fileForRef(name), content);
synchronized (this) {
--
1.6.4.msysgit.0
^ permalink raw reply related
* Re: [PATCH JGIT] Circular references shouldn't be created
From: Avery Pennarun @ 2009-09-17 21:40 UTC (permalink / raw)
To: Sohn, Matthias; +Cc: Shawn O. Pearce, Robin Rosenberg, git@vger.kernel.org
In-Reply-To: <C89280B882467443A695734861B942B28759DB95@DEWDFECCR09.wdf.sap.corp>
On Thu, Sep 17, 2009 at 3:23 PM, Sohn, Matthias <matthias.sohn@sap.com> wrote:
> void link(final String name, final String target) throws IOException {
> + if (name.equals(target))
> + throw new IllegalArgumentException(
> + "illegal circular reference : symref " + name
> + + " cannot refer to " + target);
This isn't a very thorough fix. It doesn't catch longer loops, like
HEAD -> chicken -> HEAD
or
a -> b -> c -> d -> a
Experimenting with original git.git's implementation, I see that this
is allowed:
git symbolic-ref refs/heads/boink refs/heads/boink
It succeeds and creates a file that looks like this:
ref: refs/heads/boink
And "git show-ref refs/heads/boink" says: nothing (but returns an error code).
And "git log refs/heads/boink" says:
warning: ignoring dangling symref refs/heads/boink.
fatal: ambiguous argument 'refs/heads/boink': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions
Clearly, in git.git, symref loops are caught at ref read time, not
write time. This makes sense, since someone might foolishly twiddle
the repository by hand and you don't want to get into an infinite loop
in that case. Also, it's potentially useful to allow people to set
invalid symrefs *temporarily*, as part of a multi step process.
Have fun,
Avery
^ permalink raw reply
* [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Thiago Farina @ 2009-09-17 21:51 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-pack-objects.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 7a390e1..4494a68 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -22,15 +22,15 @@
#include <pthread.h>
#endif
-static const char pack_usage[] = "\
-git pack-objects [{ -q | --progress | --all-progress }] \n\
- [--max-pack-size=N] [--local] [--incremental] \n\
- [--window=N] [--window-memory=N] [--depth=N] \n\
- [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n\
- [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n\
- [--stdout | base-name] [--include-tag] \n\
- [--keep-unreachable | --unpack-unreachable] \n\
- [<ref-list | <object-list]";
+static const char pack_usage[] =
+ "git pack-objects [{ -q | --progress | --all-progress }] \n"
+ " [--max-pack-size=N] [--local] [--incremental] \n"
+ " [--window=N] [--window-memory=N] [--depth=N] \n"
+ " [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n"
+ " [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n"
+ " [--stdout | base-name] [--include-tag] \n"
+ " [--keep-unreachable | --unpack-unreachable] \n"
+ " [<ref-list | <object-list]";
struct object_entry {
struct pack_idx_entry idx;
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Junio C Hamano @ 2009-09-17 22:00 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <1253224300-18017-1-git-send-email-tfransosi@gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> +static const char pack_usage[] =
> + "git pack-objects [{ -q | --progress | --all-progress }] \n"
> + " [--max-pack-size=N] [--local] [--incremental] \n"
> + " [--window=N] [--window-memory=N] [--depth=N] \n"
> + " [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n"
> + " [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n"
> + " [--stdout | base-name] [--include-tag] \n"
> + " [--keep-unreachable | --unpack-unreachable] \n"
> + " [<ref-list | <object-list]";
Do you still want to keep the trailing whitespace on these lines?
^ permalink raw reply
* Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Thiago Farina @ 2009-09-17 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdjhgrjv.fsf@alter.siamese.dyndns.org>
On Thu, Sep 17, 2009 at 7:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> +static const char pack_usage[] =
>> + "git pack-objects [{ -q | --progress | --all-progress }] \n"
>> + " [--max-pack-size=N] [--local] [--incremental] \n"
>> + " [--window=N] [--window-memory=N] [--depth=N] \n"
>> + " [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n"
>> + " [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n"
>> + " [--stdout | base-name] [--include-tag] \n"
>> + " [--keep-unreachable | --unpack-unreachable] \n"
>> + " [<ref-list | <object-list]";
>
> Do you still want to keep the trailing whitespace on these lines?
I did this to maintain the same output of the old string, but if you
want I can change, what you suggest?
^ 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