* Re: [PATCH] Ask for "git program" even against git-daemon
From: Shawn O. Pearce @ 2008-06-25 23:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vr6alw28s.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> This drops backward compatibility support to ask for "git-program"
> form when talking to git-daemon. Now all git native requests use
> "git program" form over ssh, local and git transports.
>
> This needs to be held back until everybody runs git-daemon from 1.5.6.1 or
> 1.6.0 or newer.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * According to the roadmap we exchanged earlier, this should happen in a
> major release (that increments the second dewey-decimal digit from the
> left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
> have the "git daemon preparation" patch included) are released.
Agreed about holding back.
But I wonder if this patch is even worth it at some later point
in time. Are we also going to change git-daemon to stop accepting
"git-" form? Is it a worthwhile change?
--
Shawn.
^ permalink raw reply
* git rebase interactive: usability issue
From: Dmitry Potapov @ 2008-06-25 23:32 UTC (permalink / raw)
To: git
Hello All,
Today I got another user complaining that git rebase interactive
sometimes squashing changes without being told to do that. Studying the
reflog revealed what I expected to see: the user started the process of
editing of chain of patches started by "git rebase -i", and then used
"git commit --amend" to correct some of them, but at some point the
process of rebasing was stopped due to a conflict caused by some previous
changes. The user after resolving this conflict run "git commit --amend"
as he did before, without realising that this time it will squash the
current patch with the previous one.
Though the user realized his mistake after my explanation of how git
rebase works, I still believe it is a serious usability issue, because
the same command: "git commit --amend" produces drastically different
results depends on whether the rebase process stopped due to conflict
or on the "edit" mark. Moreover, the commit message of second patch is
getting lost as result of using "git commit --amend" in the former case.
Personally, I have avoided this issue because normally I don't use git
commit --amend during rebasing unless I have to correct the commit
message. Instead, I just edit files and then do "git add" on them and
then run "git rebase --continue". But latest versions of git suggest
you use "git commit --amend" during interactive rebasing and following
this advice, it is easy to fall into this trap.
The following patch disables "git commit --amend" during rebase when
the process was stopped due to conflict.
-- >8 --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Wed, 25 Jun 2008 23:23:22 +0400
Subject: [PATCH] don't allow 'commit --amend' during rebase conflict resolution
Running 'commit --amend' during git rebase is almost certainly a mistake,
which causes that two consequent patches are squashed together. Moreover,
the commit message of the second commit is silently lost. It is almost
certainly not what the user expects. In that very unlikely case when you
really want to combine two patches during rebase conflict resolution,
you can do that using "git reset --soft HEAD^" followed by "git commit".
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
builtin-commit.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index e3ad38b..d03696f 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -925,6 +925,17 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
argc = parse_and_validate_options(argc, argv, builtin_commit_usage);
+ strbuf_init(&sb, 0);
+ if (amend)
+ {
+ strbuf_addf(&sb, "%s/.dotest-merge", get_git_dir());
+ if (!access(sb.buf, F_OK)) {
+ strbuf_addstr(&sb,"/amend");
+ if (access(sb.buf, F_OK))
+ die("amend not committed yet patch?");
+ }
+ }
+
index_file = prepare_index(argc, argv, prefix);
/* Set up everything for writing the commit object. This includes
@@ -937,7 +948,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
/*
* The commit object
*/
- strbuf_init(&sb, 0);
+ strbuf_reset(&sb);
strbuf_addf(&sb, "tree %s\n",
sha1_to_hex(active_cache_tree->sha1));
--
1.5.6
^ permalink raw reply related
* Re: Searching all git objects
From: Tarmigan @ 2008-06-25 23:32 UTC (permalink / raw)
To: Sam G.; +Cc: Paul Mackerras, Shawn O. Pearce, git
In-Reply-To: <20080625231742.GT11793@spearce.org>
On Wed, Jun 25, 2008 at 4:17 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> "Sam G." <ceptorial@comcast.net> wrote:
>> We recently had a developer make a large commit (mostly centered
>> around one file) which she believed she properly pushed to a remote
>> repository last week, but looking at both her repository and the
>> remote repository, that commit is now nowhere to be found. If somehow
>> the master branch she was working on in her repository has lost the
>> reference to the commit through perhaps some errant rebasing, then
>> perhaps an object containing the commit (or an object containing the
>> file in that commit) still exists somewhere inside her .git/objects
>> directory? We haven't done any git-gc recently. If so, how can I
>> search through every single git object in her objects directory,
>> searching for perhaps a specific part of the commit string, a line in
>> the code or the filename of the file which was changed? Any help with
>> this would be greatly appreciated. Thanks!
>
> Odds are it is in her HEAD reflog. You can look for it with
> `git log -g`. If you know some part of the commit message you
> may be able to filter it down with `git log -g --grep=X` or part
> of the change with `git log -g -SX`.
If it helps, I like viewing the reflog with gitk. Like this:
gitk $(git log -g --pretty=format:%H)
Is there a shorter way to do this with gitk? It would be awesome to
have `gitk -g` .
-Tarmigan
^ permalink raw reply
* Re: [PATCH] Ask for "git program" even against git-daemon
From: Junio C Hamano @ 2008-06-25 23:36 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080625232727.GU11793@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> * According to the roadmap we exchanged earlier, this should happen in a
>> major release (that increments the second dewey-decimal digit from the
>> left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
>> have the "git daemon preparation" patch included) are released.
>
> Agreed about holding back.
>
> But I wonder if this patch is even worth it at some later point
> in time. Are we also going to change git-daemon to stop accepting
> "git-" form? Is it a worthwhile change?
This was merely responding to...
From: "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
Date: Wed, 25 Jun 2008 00:37:41 -0400
Message-ID: <20080625043741.GD11793@spearce.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> ...
> Should they use "git upload-pack" or should they look for their helper
> programs in a libexec dir? I don't think that either of these programs is
> useful to run independantly, but I don't know if finding a program that
> doesn't go in $PATH on a remote machine is going to be any fun.
IMHO they should in the future use "git upload-pack".
I do not mind not doing this at all. Remember, I am the one with more
inertia than anybody else here (holding back backward incompatible
innovations is what maintainers do).
Oh, that inertia does not have much to do with actual body weight, if
anybody is wondering ;-)
^ permalink raw reply
* Git aliases executed from wrong dir
From: Kevin Ballard @ 2008-06-25 23:44 UTC (permalink / raw)
To: Git Mailing List
If I create an alias with `git config alias.foo '!pwd'` and then run
it from a subdirectory of my repo, it prints out the root of my repo.
This prevents the ability to create aliases that take filenames, as
they simply won't work if you try and reference a file from a
subdirectory.
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Git aliases executed from wrong dir
From: Kevin Ballard @ 2008-06-25 23:49 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9777229F-27FD-4CB2-A5C7-6CA15733B8D2@sb.org>
To clarify, this only appears to affect shell aliases (i.e. ones that
start with !).
git config alias.foo 'ls-files'
Works fine from a subdir
git config alias.foo '!git ls-files'
Doesn't behave right from a subdir.
-Kevin Ballard
On Jun 25, 2008, at 4:44 PM, Kevin Ballard wrote:
> If I create an alias with `git config alias.foo '!pwd'` and then run
> it from a subdirectory of my repo, it prints out the root of my
> repo. This prevents the ability to create aliases that take
> filenames, as they simply won't work if you try and reference a file
> from a subdirectory.
>
> --
> Kevin Ballard
> http://kevin.sb.org
> kevin@sb.org
> http://www.tildesoft.com
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: [PATCH] Ask for "git program" even against git-daemon
From: Shawn O. Pearce @ 2008-06-25 23:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7viqvxw0i7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> > But I wonder if this patch is even worth it at some later point
> > in time. Are we also going to change git-daemon to stop accepting
> > "git-" form? Is it a worthwhile change?
>
> This was merely responding to...
>
> From: "Shawn O. Pearce" <spearce@spearce.org>
> Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
> Date: Wed, 25 Jun 2008 00:37:41 -0400
> Message-ID: <20080625043741.GD11793@spearce.org>
>
> Daniel Barkalow <barkalow@iabervon.org> wrote:
> > ...
> > Should they use "git upload-pack" [...]
>
> IMHO they should in the future use "git upload-pack".
Sorry I wasn't clear. I was talking about the SSH transport only.
For git:// we could just always send git-upload-pack, like your
transitional patch does. Then we stay compatible with even very
old git:// servers.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Ask for "git program" even against git-daemon
From: Junio C Hamano @ 2008-06-26 0:07 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080625235724.GV11793@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> >
>> > But I wonder if this patch is even worth it at some later point
>> > in time. Are we also going to change git-daemon to stop accepting
>> > "git-" form? Is it a worthwhile change?
>>
>> This was merely responding to...
>>
>> From: "Shawn O. Pearce" <spearce@spearce.org>
>> Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
>> Date: Wed, 25 Jun 2008 00:37:41 -0400
>> Message-ID: <20080625043741.GD11793@spearce.org>
>>
>> Daniel Barkalow <barkalow@iabervon.org> wrote:
>> > ...
>> > Should they use "git upload-pack" [...]
>>
>> IMHO they should in the future use "git upload-pack".
>
> Sorry I wasn't clear. I was talking about the SSH transport only.
> For git:// we could just always send git-upload-pack, like your
> transitional patch does. Then we stay compatible with even very
> old git:// servers.
Ok, if that is the plan, then we wouldn't even need to futureproof
git-daemon at all.
Not having to change anything is good ;-).
^ permalink raw reply
* Re: gitwiki/EclipsePlugin
From: M @ 2008-06-26 0:27 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200806252055.46132.robin.rosenberg.lists@dewire.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Robin,
first of all thanks for opening git to the eclipse users.
Robin Rosenberg schrieb:
| onsdagen den 25 juni 2008 18.34.06 skrev M:
|> Hi list,
|> I felt quite helpless when trying to get egit running as neither
|> http://git.or.cz/gitwiki/EclipsePlugin nor the README/INSTALL aren't
|> overly verbose.
|>
|> I put the idiot-proof recipe on
|> http://wiki.jcurl.org/index.php5?title=GitSvn#Eclipse_Plugin - maybe you
|> can weave it into either wiki or INSTALL?
|
| You mean they *are* overly verbose?
No, that's in fact a typo of mine. They are not overly verbose.
| Our INSTALL has a lot more details than your wiki,
Yes, surely. I didn't aim to best your wiki page (as it's THE opening
reference within my notes).
| so I'm not sure I understand your problem.
As I had never compiled or packaged an eclipse plugin before, I had my
trouble finding the relevant export and options. (Right-click, bla, and
so on).
Felt like a complete idiot at first glance. Which bothers neither you
nor me, but I almost dropped it. And that would have bothered me, so I
scratched that itch further and just recorded the successful "scratch" -
the recipe.
| ) 7: uncheck all *.test projects
| not important
the better.
| ) 10: restart eclipse with parameter -clean
| probably a good idea, though I have never needed it
fine if it does without -clean.
| We're going to set up an official update site in the not too distant
future.
That's great!
If you find the recipe (except steps 7 and 10) useful, put it into
INSTALL or the wiki page, otherwise forget about it.
Greetings,
Marcus
P.S.: Thanks for the lightning-fast reply.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhi4l8ACgkQO26gbdBiJqZaVQCfWNE3zzug+0tWEr4+86aIcYAj
zWAAnRuK+Uk0zhag7wt8AD+LZXXCRgzo
=3TJV
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Searching all git objects
From: Sam G. @ 2008-06-26 0:49 UTC (permalink / raw)
To: Tarmigan; +Cc: Paul Mackerras, Shawn O. Pearce, git
In-Reply-To: <905315640806251632m416a2406x301b857ec7faf09d@mail.gmail.com>
On Jun 25, 2008, at 4:32 PM, Tarmigan wrote:
> On Wed, Jun 25, 2008 at 4:17 PM, Shawn O. Pearce
> <spearce@spearce.org> wrote:
>> "Sam G." <ceptorial@comcast.net> wrote:
>>> We recently had a developer make a large commit (mostly centered
>>> around one file) which she believed she properly pushed to a remote
>>> repository last week, but looking at both her repository and the
>>> remote repository, that commit is now nowhere to be found. If
>>> somehow
>>> the master branch she was working on in her repository has lost the
>>> reference to the commit through perhaps some errant rebasing, then
>>> perhaps an object containing the commit (or an object containing the
>>> file in that commit) still exists somewhere inside her .git/objects
>>> directory? We haven't done any git-gc recently. If so, how can I
>>> search through every single git object in her objects directory,
>>> searching for perhaps a specific part of the commit string, a line
>>> in
>>> the code or the filename of the file which was changed? Any help
>>> with
>>> this would be greatly appreciated. Thanks!
>>
>> Odds are it is in her HEAD reflog. You can look for it with
>> `git log -g`. If you know some part of the commit message you
>> may be able to filter it down with `git log -g --grep=X` or part
>> of the change with `git log -g -SX`.
>
> If it helps, I like viewing the reflog with gitk. Like this:
> gitk $(git log -g --pretty=format:%H)
>
> Is there a shorter way to do this with gitk? It would be awesome to
> have `gitk -g` .
>
> -Tarmigan
Unfortunately I can't seem to find it in here. So at this point it
seems about 99% likely that it was never committed. Does this command
search across all branches or only the one you have checked out when
you run the git log command? And, just in case, is there any way to
search raw objects for text, either commit text, file name or content?
Thanks very much!
-Sam
^ permalink raw reply
* Re: Searching all git objects
From: Junio C Hamano @ 2008-06-26 1:00 UTC (permalink / raw)
To: Sam G.; +Cc: Tarmigan, Paul Mackerras, Shawn O. Pearce, git
In-Reply-To: <321F18C8-351F-4E91-9F00-CFE2711B67D1@comcast.net>
"Sam G." <ceptorial@comcast.net> writes:
> And, just in case, is there any way to
> search raw objects for text, either commit text, file name or content?
> Thanks very much!
Or run "git lost-found" and grep for blobs in .git/lost-found/other/*
^ permalink raw reply
* Re: Re* [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-26 1:26 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Theodore Tso, Johannes Schindelin, Johannes Sixt,
Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <7vwskdxl6z.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Reset is about resetting the index and --hard option tells it to propagate
> the change down to the work tree as well.
>
> There is no "reset to the index", so "reset -- path" would be a redundant
> way to spell "reset HEAD path" or "reset HEAD -- path" which is even more
> redundant.
>
> As long as builti-fetch.c is not a valid ref, you should be able to get
> out of the above mess by any one of:
>
> $ git reset builtin-fetch.c
> $ git reset -- builtin-fetch.c
> $ git reset HEAD builtin-fetch.c
>
> but the first one complains, saying builtin-fetch.c is not a valid ref.
>
> This may help.
And this is a cleaned-up patch that is more through.
-- >8 --
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-reset.c | 39 ++++++++++++++++++++++++++++++++++-----
t/t7102-reset.sh | 47 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 81 insertions(+), 5 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index f34acb1..a032169 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -194,8 +194,40 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
reflog_action = args_to_str(argv);
setenv("GIT_REFLOG_ACTION", reflog_action, 0);
- if (i < argc && strcmp(argv[i], "--"))
- rev = argv[i++];
+ /*
+ * Possible arguments are:
+ *
+ * git reset [-opts] <rev> <paths>...
+ * git reset [-opts] <rev> -- <paths>...
+ * git reset [-opts] -- <paths>...
+ * git reset [-opts] <paths>...
+ *
+ * At this point, argv[i] points immediately after [-opts].
+ */
+
+ if (i < argc) {
+ if (!strcmp(argv[i], "--")) {
+ i++; /* reset to HEAD, possibly with paths */
+ } else if (i + 1 < argc && !strcmp(argv[i+1], "--")) {
+ rev = argv[i];
+ i += 2;
+ }
+ /*
+ * Otherwise, argv[i] could be either <rev> or <paths> and
+ * has to be unambigous.
+ */
+ else if (!get_sha1(argv[i], sha1)) {
+ /*
+ * Ok, argv[i] looks like a rev; it should not
+ * be a filename.
+ */
+ verify_non_filename(prefix, argv[i]);
+ rev = argv[i++];
+ } else {
+ /* Otherwise we treat this as a filename */
+ verify_filename(prefix, argv[i]);
+ }
+ }
if (get_sha1(rev, sha1))
die("Failed to resolve '%s' as a valid ref.", rev);
@@ -205,9 +237,6 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
die("Could not parse object '%s'.", rev);
hashcpy(sha1, commit->object.sha1);
- if (i < argc && !strcmp(argv[i], "--"))
- i++;
-
/* git reset tree [--] paths... can be used to
* load chosen paths from the tree into the index without
* affecting the working tree nor HEAD. */
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 39ba141..96d1508 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -428,4 +428,51 @@ test_expect_success '--mixed refreshes the index' '
test_cmp expect output
'
+test_expect_success 'disambiguation (1)' '
+
+ git reset --hard &&
+ >secondfile &&
+ git add secondfile &&
+ test_must_fail git reset secondfile &&
+ test -z "$(git diff --cached --name-only)" &&
+ test -f secondfile &&
+ test ! -s secondfile
+
+'
+
+test_expect_success 'disambiguation (2)' '
+
+ git reset --hard &&
+ >secondfile &&
+ git add secondfile &&
+ rm -f secondfile &&
+ test_must_fail git reset secondfile &&
+ test -n "$(git diff --cached --name-only -- secondfile)" &&
+ test ! -f secondfile
+
+'
+
+test_expect_success 'disambiguation (3)' '
+
+ git reset --hard &&
+ >secondfile &&
+ git add secondfile &&
+ rm -f secondfile &&
+ test_must_fail git reset HEAD secondfile &&
+ test -z "$(git diff --cached --name-only)" &&
+ test ! -f secondfile
+
+'
+
+test_expect_success 'disambiguation (4)' '
+
+ git reset --hard &&
+ >secondfile &&
+ git add secondfile &&
+ rm -f secondfile &&
+ test_must_fail git reset -- secondfile &&
+ test -z "$(git diff --cached --name-only)" &&
+ test ! -f secondfile
+'
+
test_done
^ permalink raw reply related
* Re: update-index --assume-unchanged doesn't make things go fast
From: Avery Pennarun @ 2008-06-26 1:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <200806252335.05083.jnareb@gmail.com>
On 6/25/08, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 25 Jun 2008, Avery Pennarun wrote:
> > Now the catch is, if I want to implement the daemon I was talking
> > about earlier, I'd like to be able to notice untracked files (or
> > directories with untracked files) individually. Ideally, I guess the
> > best way would be to just keep a separate list of all existing files
> > that aren't in the index, and have git status look at that rather than
> > at the actual filesystem.
> >
> > Are there any suggestions for how best to do this?
>
> You can try to take a look at how (third-party and Linux only) inotify
> extension for Mercurial works. AFAIK IIRC it uses some kind of daemon
> which watches for inotify notices and updates Mercorial's equivalent
> of index.
Sorry, I asked the wrong question. I wasn't asking how to implement
the daemon, which I think I can do without much trouble. I actually
need to know how to represent the information.
I was thinking of handling updated files by doing update-index
--no-assume-unchanged on files that change. But where should I store
information about *untracked* files that have changed, so that
git-status can still report them but not have to scan them all?
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Johannes Schindelin @ 2008-06-26 1:59 UTC (permalink / raw)
To: Petr Baudis
Cc: Theodore Tso, Avery Pennarun, Junio C Hamano, Johannes Sixt,
Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <20080625224428.GB12567@machine.or.cz>
Hi,
On Thu, 26 Jun 2008, Petr Baudis wrote:
> On Wed, Jun 25, 2008 at 04:38:22PM -0400, Theodore Tso wrote:
> > On Wed, Jun 25, 2008 at 04:04:47PM -0400, Avery Pennarun wrote:
> > > How about making "git checkout" default to HEAD if no revision is
> > > supplied? There's precedent for this in, say, git-diff (and I think
> > > a few others).
> > >
> > > Incidentally, "checkout <filename>" was also the way to do a revert
> > > operation in CVS. And the way to switch branches, too, iirc. So
> > > git isn't being too unusual here. That said, the commands were
> > > deliberately renamed in svn because CVS was considered largely
> > > insane.
> >
> > The one thing I would worry about is the potential ambiguity if you do
> > something like "git checkout FOOBAR", and FOOBAR was both a branch
> > name as well as a file name. How should it be interpreted? I'd argue
> > the real problem was we conflated two distinct operations: "switching
> > to a new branch", and "reverting a file" to the same name, checkout.
> >
> > Hence the suggestion to add a new command, "git revert-file", where
> > there would be no ambiguity.
>
> Just to chime in, this reminds me of Cogito - it had cg-switch for
> switching branches (like git checkout) and cg-restore for restoring
> files in working copy (like git checkout, too; but you would pass -f if
> you wanted to overwrite existing copy).
Yeah, I was kinda disappointed that this part of Cogito never was picked
up by Git "core".
I really liked the fact that Cogito was a test-bed for UI enhancements,
and miss it a bit. It was nice how it drove the UI enhancements of Git,
and I am a little sad that Cogito was discontinued. (And no, I do not see
any contender picking up the task of driving Git's UI in the right
direction.)
> (Though, Cogito didn't quite get it right either since it tried to
> overload cg-switch with the git branch functionality of creating new
> branches. I still didn't quite come in terms with any UI model of the
> branches I know about.)
To the contrary, I think that "git branch --create <branch>" _should_
switch to the newly created branch. That is what users expect, and Cogito
got that right.
Ciao,
Dscho
^ permalink raw reply
* Re: git rebase interactive: usability issue
From: Johannes Schindelin @ 2008-06-26 2:17 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <20080625233208.GE5737@dpotapov.dyndns.org>
Hi,
On Thu, 26 Jun 2008, Dmitry Potapov wrote:
> -- >8 --
> From: Dmitry Potapov <dpotapov@gmail.com>
> Date: Wed, 25 Jun 2008 23:23:22 +0400
> Subject: [PATCH] don't allow 'commit --amend' during rebase conflict resolution
This is a very funny way to interpret the SubmittingPatches document.
Just stating a fact here.
> Running 'commit --amend' during git rebase is almost certainly a
> mistake, which causes that two consequent patches are squashed together.
> Moreover, the commit message of the second commit is silently lost. It
> is almost certainly not what the user expects. In that very unlikely
> case when you really want to combine two patches during rebase conflict
> resolution, you can do that using "git reset --soft HEAD^" followed by
> "git commit".
NACK.
You just broke the 'edit' command.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] pre-commit hook should ignore carriage returns at EOL
From: Christian Holtje @ 2008-06-26 2:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vhcbh1g4e.fsf@gitster.siamese.dyndns.org>
On Jun 25, 2008, at 3:14 PM, Junio C Hamano wrote:
> Christian Holtje <docwhat@gmail.com> writes:
>>
>> Junio, do you want me to make this change anyway? It does make
>> sense.
>> The unittests for the pre-commit hook may or may not still be
>> useful.
>
> "disable" is not an issue. The intention has always been that these
> are
> samples, and it was an accident that some packaging shipped them
> enabled
> by mistake. The patch was to make that mistake harder to make.
>
> The issue now is about keeping the example hooks _relevant_. The
> one we
> have does not work well with projects that want to check in files with
> CRLF line endings (iow, without using autocrlf to attempt to make the
> project files cross-platform), so it is irrelevant for such projects
> with
> Windows origin.
>
> The "solution" you are proposing to strip out \r makes the check less
> useful for projects that want to keep files with LF line endings in
> the
> commited history, because your patch would stop catching such a
> mistake of
> adding an CR before LF. It is robbing from Peter to pay Paul, and I
> am
> afraid it would make the sample even more irrelevant in the end. I
> do not
> think we would want to go there.
>
> I suggested using "diff --check" (and possibly teaching "diff --check"
> other things the scripted example checks, such as conflict markers),
> which would know to honor the line endings specified per path via
> gitattributes(5), instead of building on top of the big Perl script,
> and I
> had an impression that you agreed to the approach.
I'm completely confused how gitattributes and core.autocrlf interact,
etc.
I'm expecting the default behavior is that git will leave my files
alone. This seems to be the case.
In order for the crlf stuff to work, does it need to have
core.autocrlf set to true? If so, that seems wrong. gitattributes(5)
is supposed to let you have fine grain control over files. In
addition, .git/config isn't passed around via clone so .gitattributes
works differently depending on who clones it and their settings.
Furthermore, how would 'git diff --check' know what the line endings
are for a file? I may have a mostly unix repository but I may have a
few crlf text files I need to have checked out as crlf on windows (but
not unix).
Shouldn't the crlf stuff be something like:
.gitattributes:
eol=crlf -- dos files. no conversion, but diff --check will know
what is what.
eol=lf -- unix (otherwise same)
eol=convert -- stores internally as lf, converts on the fly to lf
or crlf on filesystem based on system preference. diff --check won't
worry about new lines matching system-eol if they don't match the eol
in the file.
eol=binary -- binary
core.eol=crlf -- ony files with all crlf endings are text.
core.eol=lf -- only files with all lf (no crlf) endings are text.
core.eol=convert -- crlf changes will be converted to lf as per system-
eol
core.eol=false -- do nothing (default) (binary)
core.system-eol=crlf -- pretend the system is windows
core.system-eol=lf -- pretend the system is unix
core.system-eol=auto -- determine from the system (default)
Otherwise, I have no clue what's going on. Once someone writes this
in english, I'll try to write unittests and I'll submit them. Then
someone who knows what he/she is doing can write the actual code to
make the tests pass. Or maybe I'll try, who knows.
Ciao!
^ permalink raw reply
* Re: git rebase interactive: usability issue
From: Junio C Hamano @ 2008-06-26 3:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, git
In-Reply-To: <alpine.DEB.1.00.0806260416410.4503@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> NACK.
>
> You just broke the 'edit' command.
Really? I thought it would be Ok for "edit" command.
The patch checks the presense of /amend and complains only if it does not
exist, while you create /amend when you respond to "edit" insn.
I was relunctant about the patch not because of "edit", but because I am
not convinced that it will _never_ make sense to be able to amend while
the sequence stops with a conflict (as the patch does not give us any way
to override this rather heavy-handed denial to continue).
I also was hoping that with enough hooks git-commit already calls, this
could have been experimented and implemented with hooks without touching C
layer at least initially, while people can convince themselves that the
approach is sane (i.e. it _never_ makes sense to do amend upon conflict).
^ permalink raw reply
* Re: Windows symlinks
From: Jay Soffian @ 2008-06-26 3:50 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Patrick.Higgins@cexp.com, git
In-Reply-To: <32541b130806241618p69f6167dycb09cdec1af8ba0@mail.gmail.com>
On Tue, Jun 24, 2008 at 7:18 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> My understanding of Clearcase is that it actually loads a virtual
> filesystem driver in Windows and does all kinds of insane magic -
Just FYI, this is only the case if you're using so-called dynamic
views, which require the MVFS
driver, as you say. The OP said he was using snapshot views -- these
don't use MVFS and instead just checkout to the OS's native
filesystem.
j.
^ permalink raw reply
* Re: git rebase interactive: usability issue
From: Avery Pennarun @ 2008-06-26 3:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Dmitry Potapov, git
In-Reply-To: <7vbq1ovpl7.fsf@gitster.siamese.dyndns.org>
On 6/25/08, Junio C Hamano <gitster@pobox.com> wrote:
> I was relunctant about the patch not because of "edit", but because I am
> not convinced that it will _never_ make sense to be able to amend while
> the sequence stops with a conflict (as the patch does not give us any way
> to override this rather heavy-handed denial to continue).
Perhaps the problem is more that people are encouraged to --amend so
often that they end up doing it by accident.
What if 'edit' worked more like 'squash', in that it produced the new
tree, but didn't commit it yet? Then you can reset things, commit
them, or rebase --continue (which commits automatically if needed)
just like wish 'squash'.
I think --continue used to not commit automatically, so I can see why
edit used to commit for you, but maybe that behaviour is not needed
anymore.
Right now the asymmetry of having to use --amend with 'edit' but not
with 'squash' is what leads me to make mistakes sometimes.
Have fun,
Avery
^ permalink raw reply
* Re: about c8af1de9 (git status uses pager)
From: Dan McGee @ 2008-06-26 3:53 UTC (permalink / raw)
To: git
In-Reply-To: <20080622072420.GA5161@dualtron.vpn.rwth-aachen.de>
On 06/22/2008 05:01 AM, Junio C Hamano wrote:
>> Having said all that, I have to say I am regretting to have accepted that
>> patch to enable pager on status, not because it bothers me personally (it
>> doesn't primarily because I practically never run git-status because I
>> consider the command useless and living almost always in Emacs helps), but
>> because in principle changing anything that existing users are used to is
>> bad.
I'm a bit late on the uptake here, but I wanted to throw my two cents in- this was one of the biggest usability flubs I've seen with git in a long time. I suspect (actually, I *know*) there were many users like I that used git-status all the time in the console to get a handle on what their work tree was looking like. That became impossible with 1.5.6 out of the box, and I have to spend an hour reading mailing list posts trying to restore the former non-broken behavior.
Why did this patch get pulled in with so little discussion? Didn't someone think that there must be a reason git-status didn't use a pager before?
On 06/22/2008 02:24 AM, Johannes Gilger wrote:
> On 21/06/08 23:42, Johannes Gilger wrote:
>> Wow, I just noticed it myself. Why was that changed? I don't know about
>> your status lines, but I for one find it really annoying. Anything
>> that's in a pager isn't visible in my console afterwards. What's next?
>> git branch in a pager too?
>
> Seems like I got ahead of myself there. After setting the core.pager to
> less -FRSX everything works fine ;)
This is a terrible thing to force users to have to do. Not only that, but the interaction between GIT_PAGER, core.pager, and everything else just makes this change even more hard to swallow.
I probably came across as flame/troll here, but I felt I needed to speak up for those of us that never knew this change was coming. I would go so far as to say this should be reverted for a maint release.
-Dan
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-26 5:16 UTC (permalink / raw)
To: Theodore Tso
Cc: Avery Pennarun, Johannes Schindelin, Johannes Sixt, Boaz Harrosh,
Steven Walter, git, jeske
In-Reply-To: <7vod5pxknh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Theodore Tso <tytso@mit.edu> writes:
>
>> On Wed, Jun 25, 2008 at 01:50:06PM -0700, Junio C Hamano wrote:
>>> I just replied to Avery about that. -- is always the way to disambiguate
>>> between refs (that come before --) and paths (that come after --), not
>>> limited to "git checkout" but with other commands such as "git log", "git
>>> diff", etc.
>>
>> Stupid quesiton --- where is this documented? I don't see this
>> documented either in the man page for git or git-checkout.
>
> You are asking a wrong person. My git knowledge mostly comes from
> yearlong reading of the mailing list articles, and doing a bit myself also
> helps ;-).
I couldn't find a good central place to place this as this is more or less
used consistently throughout the UI (log, diff, grep, and then I just
fixed reset as well).
Whereever the description should end up to be in, here is what I think we
should talk about.
Documentation/gitcli.txt | 37 +++++++++++++++++++++++++++++++++----
1 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 8fb5d88..2316049 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -13,8 +13,37 @@ gitcli
DESCRIPTION
-----------
-This manual describes best practice in how to use git CLI. Here are
-the rules that you should follow when you are scripting git:
+This manual describes the convention used throughout git CLI.
+
+Many commands take revisions (most often "commits", but sometimes
+"tree-ish", depending on the context and command) and paths as their
+arguments. Here are the rules:
+
+ * Revisions come first and then paths.
+ E.g. in `git diff v1.0 v2.0 arch/x86 include/asm-x86`,
+ `v1.0` and `v2.0` are revisions and `arch/x86` and `include/asm-x86`
+ are paths.
+
+ * When an argument can be misunderstood as either a revision or a path,
+ they can be disambiguated by placing `\--` between them.
+ E.g. `git diff \-- HEAD` is, "I have a file called HEAD in my work
+ tree. Please show changes between the version I staged in the index
+ and what I have in the work tree for that file". not "show difference
+ between the HEAD commit and the work tree as a whole". You can say
+ `git diff HEAD \--` to ask for the latter.
+
+ * Without disambiguating `\--`, git makes a reasonable guess, but errors
+ out and asking you to disambiguate when ambiguous. E.g. if you have a
+ file called HEAD in your work tree, `git diff HEAD` is ambiguous, and
+ you have to say either `git diff HEAD \--` or `git diff \-- HEAD` to
+ disambiguate.
+
+When writing a script that is expected to handle random user-input, it is
+a good practice to make it explicit which arguments are which by placing
+disambiguating `\--` at appropriate places.
+
+Here are the rules regarding the "flags" that you should follow when you are
+scripting git:
* it's preferred to use the non dashed form of git commands, which means that
you should prefer `"git foo"` to `"git-foo"`.
@@ -34,8 +63,8 @@ the rules that you should follow when you are scripting git:
if you happen to have a file called `HEAD` in the work tree.
-ENHANCED CLI
-------------
+ENHANCED OPTION PARSER
+----------------------
From the git 1.5.4 series and further, many git commands (not all of them at the
time of the writing though) come with an enhanced option parser.
^ permalink raw reply related
* Re: policy and mechanism for less-connected clients
From: Theodore Tso @ 2008-06-26 5:23 UTC (permalink / raw)
To: David Jeske; +Cc: Junio C Hamano, git
On Wed, Jun 25, 2008 at 11:03:02PM -0000, David Jeske wrote:
> I don't want to replicate CVS behavior, just the workflow.
It's not clear exactly what you want. If you want the CVS workflow
(with all of its downsides), then just use "git pull; hack hack hack;
git push" all on the master branch. If you are going to preserve the
workflow of CVS, then you're also going to preserve all of the
downsides of CVS. If you aren't willing to make the users learn
anything new, then what's the point?
And if you are willing to make the users change their behaviour a
somewhat -- how much change are you willing to make them deviate from
the CVS workflow, and how much smarts are you willing to assume that
they have?
- Ted
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Junio C Hamano @ 2008-06-26 5:26 UTC (permalink / raw)
To: Theodore Tso; +Cc: David Jeske, git
In-Reply-To: <20080626052310.GC8610@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Wed, Jun 25, 2008 at 11:03:02PM -0000, David Jeske wrote:
>> I don't want to replicate CVS behavior, just the workflow.
>
> It's not clear exactly what you want. If you want the CVS workflow
> (with all of its downsides), then just use "git pull; hack hack hack;
> git push" all on the master branch.
Eh, my point was more about "to preserve CVS workflow, fetch+rebase+push
is much closer than pull+push"...
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Andreas Ericsson @ 2008-06-26 5:31 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Junio C Hamano, Steven Walter, git, jeske
In-Reply-To: <48620C1A.6000509@panasas.com>
Boaz Harrosh wrote:
> Junio C Hamano wrote:
>> Steven Walter <stevenrwalter@gmail.com> writes:
>>
>>> @@ -225,6 +243,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
>>> if (reset_type == HARD && is_bare_repository())
>>> die("hard reset makes no sense in a bare repository");
>>>
>>> + if (reset_type == HARD && !force && index_is_dirty()) {
>>> + die("Uncommitted changes; re-run with -f to trash them");
>>> + }
>>> +
>> Please don't. With your change, does the testsuite even pass?
>>
>> "reset --hard" has *ALWAYS* meant to be destructive --- discarding
>> potential local cruft is the whole point of the operation.
>>
>
> I was under the impression that --hard means working-directory-also
> as opposed to tree-and-index-only. Nothing to do with
> destructive-discarding. If it is then something is missing.
> I need 2 distinct functions. You combine to functions under
> one command.
>
>> Learn the lingo, and get over it.
>>
>
> I did lern the lingo and got bitten. I wanted to do one thing
> also got the other one.
>
> there is:
> git-reset --clean - destructive-discarding any local changes
> git-reset --hard - move tree index and working directory to new head
>
> How can I separate between them, Please
>
There is a "--hard" after one of them. It reads like this:
git reset --hard ;# move current branch to random point in history
# discarding working tree and index state
git reset --mixed ;# move current branch to random point in history
# discard the index but keep the working tree
git reset --soft ;# move current branch to random point in history,
# leaving index and working tree intact
It's under OPTIONS in the man-page. --mixed is default.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Jeff King @ 2008-06-26 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lea Wiemann, Git Mailing List
In-Reply-To: <20080625161433.GA6612@sigill.intra.peff.net>
On Wed, Jun 25, 2008 at 12:14:33PM -0400, Jeff King wrote:
> Hmm. Actually, there is a test in t6300 that runs with each atom name.
> Unfortunately, it doesn't bother actually checking the output for
> sanity, so the fact that these atoms returned the empty string was
> missed.
And here is a two patch series cleaning up the test script and fixing
the bug.
-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