* Re: [PATCH] Make --color available to git-status
From: Matthieu Moy @ 2007-05-06 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705051956200.4015@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sat, 5 May 2007, Matthieu Moy wrote:
>
>> Git has a nice colored output for status, using
>>
>> $ git runstatus --color
>>
>> However, this --color is not made available to git-status itself.
>
> AFAIR there have been attempts to enable this by default, when git-status
> is run interactively (i.e. its output is not piped). However, this proved
> to be remarkably complex, given that the output of runstatus _is_ piped.
It would definitely be cool to have it enabled by default, but just
having the option (which means in particular that users can use it in
an alias) should be the minimum.
I don't have enough experience with git hacking to do all the way you
suggest, so I'm starting with easy things ;-).
--
Matthieu
^ permalink raw reply
* Re: [StGIT PATCH] Test "stg rebase" after "stg commit"
From: Karl Hasselström @ 2007-05-06 14:22 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git
In-Reply-To: <20070506133909.GG19253@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-05-06 15:39:09 +0200, Yann Dirson wrote:
> Well, this case clearly falls in the category of "actions outside
> stgit that make it possible to rebase without a loss". But then it
> is also clear that the action of tagging makes the committed patch
> reachable, and thus the rebase loss-less.
>
> The safety check could be possibly be rewritten as "check if current
> base is reachable without using any refs from current series".
Yes, I like that idea _much_ better. That's what we _should_ be
testing for, given that the objective is to keep all commits
reachable.
So, how can we do that? gitk displays, when you view a commit, the
heads through which that commit is reachable. How does it compute
that? Hmm, it seems like this type of construct works for selecting
only those commits that are only reachable through a given ref:
gitk origin/pu --not $(git show-ref | grep -v refs/remotes/origin/pu| cut -f 1 -d ' ')
Of course, one could use git log instead of gitk if it turns out to be
too hard to write an x-windows parser for stgit. :-)
However, I'm not sure even this is necessary; reflogs are enabled by
default nowadays. But if it's cheap enough, we might as well.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Johannes Schindelin @ 2007-05-06 15:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dana How, Git Mailing List, Shawn O. Pearce
In-Reply-To: <7vwszmfod8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 5 May 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> (a) In a bare repository, I believe
> >> setup.c:setup_git_directory_gently() determines the prefix to be
> >> NULL. This means my patch will see ALL paths as absolute, except
> >> :../path which will result in an error.
> >
> > My point was that it feels inconsistent to take the current path into
> > account in one case, but not in the other.
>
> I do not understand your reasoning. In a bare repository you cannot
> even be in a subdirectory to begin with.
Exactly! That is my point. If you can do it in a working directory, but
also with a bare repository, I find it highly confusing and inconsistent
to have different meaning.
Ciao,
Dscho
^ permalink raw reply
* [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-06 15:13 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The name of the current patch, if any, is always the last line of
patches/<branch>/applied (and there is no current patch if and only if
the "applied" file is empty). So use that instead, and stop having to
worry about keeping the redundant "current" file up-to-date.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
This is another remove-redundant-metadata cleanup patch. Not only does
it remove more code than it adds, the removed code (mostly calls to
__set_current) is the kind that one easily forgets to insert in the
proper places when writing new code.
stgit/stack.py | 35 +++++++++--------------------------
1 files changed, 9 insertions(+), 26 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index 2477ac6..3e9fc4f 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -295,7 +295,6 @@ class Series(StgitObject):
self.__applied_file = os.path.join(self._dir(), 'applied')
self.__unapplied_file = os.path.join(self._dir(), 'unapplied')
self.__hidden_file = os.path.join(self._dir(), 'hidden')
- self.__current_file = os.path.join(self._dir(), 'current')
self.__descr_file = os.path.join(self._dir(), 'description')
# where this series keeps its patches
@@ -325,11 +324,6 @@ class Series(StgitObject):
"""
return self.__name
- def __set_current(self, name):
- """Sets the topmost patch
- """
- self._set_field('current', name)
-
def get_patch(self, name):
"""Return a Patch object for the given name
"""
@@ -346,11 +340,16 @@ class Series(StgitObject):
def get_current(self):
"""Return the name of the topmost patch, or None if there is
no such patch."""
- name = self._get_field('current')
- if name == '':
+ try:
+ applied = self.get_applied()
+ except StackException:
+ # No "applied" file: branch is not initialized.
+ return None
+ try:
+ return applied[-1]
+ except IndexError:
+ # No patches applied.
return None
- else:
- return name
def get_applied(self):
if not os.path.isfile(self.__applied_file):
@@ -650,8 +649,6 @@ class Series(StgitObject):
os.remove(self.__unapplied_file)
if os.path.exists(self.__hidden_file):
os.remove(self.__hidden_file)
- if os.path.exists(self.__current_file):
- os.remove(self.__current_file)
if os.path.exists(self.__descr_file):
os.remove(self.__descr_file)
if os.path.exists(self._dir()+'/orig-base'):
@@ -825,11 +822,8 @@ class Series(StgitObject):
self.log_patch(patch, 'new')
insert_string(self.__applied_file, patch.get_name())
- if not self.get_current():
- self.__set_current(name)
else:
append_string(self.__applied_file, patch.get_name())
- self.__set_current(name)
if refresh:
self.refresh_patch(cache_update = False, log = 'new')
@@ -936,8 +930,6 @@ class Series(StgitObject):
f.writelines([line + '\n' for line in unapplied])
f.close()
- self.__set_current(name)
-
return forwarded
def merged_patches(self, names):
@@ -1019,8 +1011,6 @@ class Series(StgitObject):
f.writelines([line + '\n' for line in unapplied])
f.close()
- self.__set_current(name)
-
# head == bottom case doesn't need to refresh the patch
if empty or head != bottom:
if not ex:
@@ -1098,11 +1088,6 @@ class Series(StgitObject):
f.writelines([line + '\n' for line in applied])
f.close()
- if applied == []:
- self.__set_current(None)
- else:
- self.__set_current(applied[-1])
-
def empty_patch(self, name):
"""Returns True if the patch is empty
"""
@@ -1144,8 +1129,6 @@ class Series(StgitObject):
f.close()
elif oldname in applied:
Patch(oldname, self.__patch_dir, self.__refs_dir).rename(newname)
- if oldname == self.get_current():
- self.__set_current(newname)
applied[applied.index(oldname)] = newname
^ permalink raw reply related
* How to set git commit timestamp
From: Guido Ostkamp @ 2007-05-06 16:03 UTC (permalink / raw)
To: git
Hello,
does somebody know a method to specify a timestamp for a 'git commit'?
I am writing a tool to convert from another SCM to git and need to replay
all checkins. I know how to set the log message and the author, but there
appears to be no command option for the timestamp (Mercurial for example,
has a 'hg commit -d date <file>' syntax for this).
Any help is appreciated.
Regards
Guido
^ permalink raw reply
* [FAQ?] Rationale for git's way to manage the index
From: Matthieu Moy @ 2007-05-06 16:10 UTC (permalink / raw)
To: git
Hi,
I've read the manual, and I belive I have a correct understanding of
how the index works, technically speaking. Still, I'm not clear about
the rational for such design.
Almost any other decent system has an equivalent to cache the stat
information (bzr calls this stat-cache, hg calls it dirstate IIRC).
That is, if your run "$vcs diff" twice, the second run will only need
to stat all files, never diff them.
But the fact that git actually remembers the _content_ of files in the
index, and that the default behavior for "commit" is to commit only
the content that is explicitely "git add"ed is something I've never
seen outside git.
At first, I find it rather annoying. My usual workflow is
<hack hack hack>
% $vcs status
% $vcs commit -m "describe whatever I did"
<hack hack hack>
...
With git, i'd do
<hack hack hack>
% git status
% git add X
% git add Y
% git status
% git commit
or
<hack hack hack>
% git satus -a
% git commit -a -m "..."
In the former case, I have more commands to type, and in the second
case, I loose part of the stat-cache benefit: If I run "git status -a"
twice, the second run will actually diff all the files touched since
the last run, since "git status -a" actually updated a temporary
index, and discarded it afterwards, so it doesn't update the stat
information in the index (while "git status" would have).
In both cases, I can't really see the benefit. I'm pretty sure this is
a FAQ, and I'm also pretty sure there are good arguments for it, but I
can't find it anywhere.
Thanks for your answers,
--
Matthieu
^ permalink raw reply
* Wiki front page pointing to HelpOnLanguages
From: Matthieu Moy @ 2007-05-06 16:15 UTC (permalink / raw)
To: git
Hi,
Both the URL http://git.or.cz/gitwiki/ and the link "GitWiki" on the
top-left corner of the wiki seem to point to
http://git.or.cz/gitwiki/HelpOnLanguages which is a MoinMoin-dedicated
page, but very confusing for someone looking for informations about
git.
Reproduced with both Firefox, Konqueror and links, configured in
English AFAICT, from two different machines.
--
Matthieu
^ permalink raw reply
* Re: Git branch bug
From: Daniel Barkalow @ 2007-05-06 16:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Guido Ostkamp, git
In-Reply-To: <7vabwih3bd.fsf@assigned-by-dhcp.cox.net>
On Sat, 5 May 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This leaves open the question of how you make your initial commit in a
> > branch that isn't master. I think the answer should be:
> >
> > $ git checkout -b experimental
> > warning: You appear to be on a branch yet to be born.
> > warning: Forcing checkout of HEAD.
> > fatal: just how do you expect me to merge 0 trees?
> >
> > Which should probably be:
> >
> > $ git checkout -b experimental
> > warning: You appear to be on a branch yet to be born.
> > warning: Putting you on a new branch yet to be born.
> >
> > And leaving .git/HEAD pointing to refs/heads/experimental instead of
> > refs/heads/master, with refs/heads/ still empty.
>
> While I agree that is probably correct, it would not be useful
> in real-life that much. When you do not even have 'master', I
> do not think there is much point of being able to create two
> useless, yet-to-be-born branches.
The point is that you may not want to have a branch named "master", but
rather want your first branch to be named something else. Your project
could be such that "master" would be a confusing term to use for a
default branch. Currently, it's awkward to start a project that avoids
that particular name, which is what it seemed to me that the original
poster was trying to do.
I don't think it's useful to be able to switch to a new yet-to-be-born
branch from any other state, but I do think it's useful to be able to
choose what the first branch is.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Linus Torvalds @ 2007-05-06 16:38 UTC (permalink / raw)
To: Karl Hasselstr?m
Cc: Paul Mackerras, Junio C Hamano, Carl Worth, Michael Niedermayer,
Git Mailing List
In-Reply-To: <20070506101953.GA17498@diana.vm.bytemark.co.uk>
On Sun, 6 May 2007, Karl Hasselstr?m wrote:
>
> OK, now I've tested it, and just as you said, it works (and is _very_
> useful) but looks like crap. :-)
>
> Is there any fundamental reason why
>
> gitk -- some/path/name
>
> generates a nice, connected graph, while
>
> gitk -S'some string'
>
> generates disconnected spaghetti?
There is a reason, and it's fairly fundamental: the path limiting code is
deeply embedded in the revision walking, and I've spent a fair amount of
effort on making that work and efficient as hell (it's one of the few
areas in git where I'm probably still the main author). Because it's
literally what I do 90% of the time: for me, the path-limiting code is
basically _the_ most important git feature, and I care very deeply.
In contrast, the "-S" thing is not actually part of the revision walking
at all, and is a totally separate phase that is done when revisions are
_shown_. I almost never use it myself, and it grew out of a totally
separate effort by Junio.
> Or could the latter be made to use the same parent-rewriting logic as
> the first?
It would probably be possible to make the -S logic be another part of the
"prune_fn()" logic in revision.c, and it might even simplify some of the
logic, but I suspect it would actually suck really really badly from a
performance standpoint.
Why? Because the prune_fn() logic is done when we generate the revision
graph, which is generally something that a lot of the operations have to
do up-front before they can do _anything_ else. Eg, any revision limiter
(and that's a very common case) like "v2.6.21.." will cause the revision
pruning to happen synchronously and early on.
And the path-limiting is *fast*. It's so incredibly fast that people don't
really realize how fast it is. And it absolutely needs to be fast, because
when you do something like "gitk v2.6.18.. drivers/" on the kernel you end
up doing a _lot_ of tree comparisons. It's why I'm pretty sure nobody else
can ever do what git does - it takes full advantage of how git can tell
that a whole subdirectory hasn't changed without even recursing into it.
In contrast, "-S" is _slow_. It's a really really expensive operation. Git
makes generating diffs faster than just about anything else, but it's
still really expensive. This is a really unfair comparison, but:
time git log drivers/net/ > /dev/null
real 0m1.488s
user 0m1.444s
sys 0m0.040s
ie we can do the log pruning for the whole kernel git history on a
subdirectory in less than two seconds.
Try to compare it with
time git log -Sdrivers/net/ > /dev/null
and I suspect you won't have the patience to wait for the end result.
And yeah, the operations are fundamentally very very different, and yes,
the latter operation is really really expensive (which is why I said it's
a really unfair comparison). But the point is that the expense comes from
how git has been designed: seeing differences in the paths is cheap by
design (it's how the data structures are laid out), but seeing differences
in actual diffs means that we have to fully generate each diff for each
revision!
A different approach to the underlying datastructures could change the
equation. For example, if the fundamental data representation was the
"diff" (rather than the "whole tree") maybe -S would be as fast as path
limiting. But you'd *really* suck for other things.
To summarize a long story: the path limiting is simply more fundamental in
git. Both by design, and then - obviously partly _due_ to that - by pure
effort we've spent on it. It's something very deep and very important. In
comparison, the -S thing is a cute extra feature, nothing really "deep".
Linus
^ permalink raw reply
* Re: How to set git commit timestamp
From: Alex Riesen @ 2007-05-06 16:41 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705061759210.8165@bianca.dialin.t-online.de>
Guido Ostkamp, Sun, May 06, 2007 18:03:14 +0200:
>
> does somebody know a method to specify a timestamp for a 'git commit'?
>
Set GIT_AUTHOR_DATE (and maybe GIT_COMMITTER_DATE) in the environment.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Johannes Schindelin @ 2007-05-06 16:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqwszm9bm9.fsf@bauges.imag.fr>
Hi,
On Sun, 6 May 2007, Matthieu Moy wrote:
> [...]
>
> % git satus -a
> % git commit -a -m "..."
>
> In the former case, I have more commands to type, and in the second
> case, I loose part of the stat-cache benefit: If I run "git status -a"
> twice, the second run will actually diff all the files touched since
> the last run, since "git status -a" actually updated a temporary
> index, and discarded it afterwards, so it doesn't update the stat
> information in the index (while "git status" would have).
Have you tried "git status" _without "-a"?
> In both cases, I can't really see the benefit.
The benefit is a clear distinguishing between DWIM and low level. The
index contains _exactly_ what you told it to contain. By forcing users to
use "-a" with "git commit", you make it clear that a separate update
steo is involved, and if you made an error (which you see from the file
list), you can abort, and start over with the original index.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] diff: release blobs after generating textual diff.
From: Nicolas Pitre @ 2007-05-06 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6pucp9e.fsf@assigned-by-dhcp.cox.net>
On Sun, 6 May 2007, Junio C Hamano wrote:
> This reduces the memory pressure when dealing with many paths.
>
> An unscientific test of running "diff-tree --stat --summary -M"
> between v2.6.19 and v2.6.20-rc1 in the linux kernel repository
> indicates that the number of minor faults are reduced by 2/3
> (153k vs 49k).
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> * This is still a WIP, not in the sense that it breaks anything
> (it doesn't seem to), but in the sense that it is not known
> if it is useful in general and would make that much of a
> difference with a project much larger than the kernel.
This can only be good. People are really starting to use Git with
gigantic repos on limited memory hardware.
Nicolas
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Linus Torvalds @ 2007-05-06 17:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqwszm9bm9.fsf@bauges.imag.fr>
On Sun, 6 May 2007, Matthieu Moy wrote:
>
> But the fact that git actually remembers the _content_ of files in the
> index, and that the default behavior for "commit" is to commit only
> the content that is explicitely "git add"ed is something I've never
> seen outside git.
Yeah. You'd better get used to it, because it's fundamental.
Here's the rationale list:
- It's fundamentally the only sane thing to do.
Git tracks content at _all_ levels, not "files". So this is more than
an implementation issue, it's a fundamental "how the world works"
issue. The fact that everybody else gets it wrong is _their_ problem.
[ Corollary: the fact that your brain has rotted from using those
broken systems is obviously your problem, and sadly, there's nothing
else we can do than try to show the right way and hope that the
neurons re-generate. CVS has caused endless suffering, this is just
one small example of it ]
- You fundamentally cannot do it any other way.
Not doing it the way git does it (point to the content) means that the
index-replacement has to point to something else, namely a "file ID".
That's so broken as to be really really sad. In CVS, for example, there
obviously isn't any "file ID", so what does the "index" in CVS point
at?
Right. The "index" in CVS is the Entries file, and it not only lacks
stat information, it also lacks any other information, which means that
the "file ID" is _literally_ just the pathname itself. That causes
obvious problems, so nobody sane would ever suggest that this is a good
idea.
So what do other people use? They tend to not have understood the
"content is king" thing (which is what git uses), so they add somethng
*else* to the "index" file than the content. What can I say? People are
morons. I'm constantly amazed at just how stupid SCM people seem to be.
In most systems, that "something else" is a "file ID". That just means
that they are fundamentally broken whenever they do any trivial merge
with renames. Just don't do it. I've talked before about why tracking
file ID's is wrong - it's just as wrong as thinking that the "ID" of a
file is the path.
- Tracking content in the index is fundamentally how and why git can do
merges so much better than anything else, and how we handle conflicts
gracefully.
Trust me, you haven't seen good merge conflict support until you've
done a git merge, and realized that you can do things like just
git diff
to see just the *conflicting* parts, not the stuff you don't need to
worry about. And it's why you can do
git diff --base/--ours/--theirs
to see what the diffs of the conflicting files are wrt the versions
that got us there. Again, a big part of this is that the index tracks
*content* rather than some totally idiotic secondary notion that has
nothing to do with anything sane.
That's the three major reasons. The first one may not seem relevant to
you, but when you start to understand that "content is the only thing that
matters", you'll move to a whole new level. Not just in git, but in
general. So the first argument is purely philosophical, but it's still
important.
The two other rationales are purely practical. It's why git is simply
_better_ than the alternatives. It's why git can do things that others
cannot do, or that they have to do strange and weird things for, and git
does totally naturally without having to even think about it.
A file-ID-based thing will always have fundamental problems with file ID
clashes - issues that cause annoyances both small and big. Git just
doesn't have that fundamental design bug.
> At first, I find it rather annoying. My usual workflow is
You'll just need to get used to it. The git way is actually much better.
You'll get used to it quickly enough, but once you do, what's the problem
with the workflow you already quote:
> <hack hack hack>
> % git status -a
> % git commit -a -m "..."
What's so hard with adding that "-a" to "git commit"? You don't even need
it on the status line, the status is relevant and understandable (and
actually tells you more) even without it.
> In the former case, I have more commands to type, and in the second
> case, I loose part of the stat-cache benefit: If I run "git status -a"
> twice, the second run will actually diff all the files touched since
> the last run, since "git status -a" actually updated a temporary
> index, and discarded it afterwards, so it doesn't update the stat
> information in the index (while "git status" would have).
WHY do you care?
Git is still about an order of magnitude faster than anything that you can
compare with, so I really don't see what you're complaining about?
You seem to be complaining about the fact that:
- git does extra and unnecessary work when you give it an extra and
unnecessary flag (the "-a" to "git status".
- despite the fact that you can make git do unnecessary things, I can
pretty much guarantee that your workflow is still faster with git than
with pretty much anything else, so why complain?
So both of your complaints seem to be a bit pointless to me. But the real
answer really is:
- git does things better, and the git approach actually allows you a
better workflow. Now, admittedly that better workflow is especially
notable when you have a merge conflict or other nastier situation and
not as obvious when you just don't do anything exciting, but it's
actually also more *logical* even in the absense of any merge issues
(ie the whole "content vs filenames" issue).
- but git doesn't *force* that better workflow, and you can always just
use "git commit -a" to emulate the stupidity that is CVS and SVN.
Basically, I use the "git commit -a" for all the trivial cases, but
equally often I carry around independent changes in my tree (often for
long times - right now my tree has some experimental stuff I haven't
committed yet in fs/ext3/ialloc.c for example) and I work with a dirty
tree and commit and change _parts_ of it. And then the "-a" thing is
wrong, and having it as the default would just cause mistakes.
So git really does the right thing, for so many reasons. But yeah, the
right thing is different from what CVS does.
(That statement is so true that it basically could be used ass a
definition of CVS: "tThe right thing is different from what CVS does" is
not about the index, it's about almost _everything_)
Linus
^ permalink raw reply
* Re: How to set git commit timestamp
From: René Scharfe @ 2007-05-06 17:26 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705061759210.8165@bianca.dialin.t-online.de>
Guido Ostkamp schrieb:
> Hello,
>
> does somebody know a method to specify a timestamp for a 'git commit'?
>
> I am writing a tool to convert from another SCM to git and need to
> replay all checkins. I know how to set the log message and the author,
> but there appears to be no command option for the timestamp (Mercurial
> for example, has a 'hg commit -d date <file>' syntax for this).
You can use the environment variable GIT_COMMITTER_DATE to force a
specific commit date. Please see the man page of git-commit-tree for
(some) more info.
René
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Matthieu Moy @ 2007-05-06 17:34 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705061851411.4015@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sun, 6 May 2007, Matthieu Moy wrote:
>
>> [...]
>>
>> % git satus -a
>> % git commit -a -m "..."
>>
>> In the former case, I have more commands to type, and in the second
>> case, I loose part of the stat-cache benefit: If I run "git status -a"
>> twice, the second run will actually diff all the files touched since
>> the last run, since "git status -a" actually updated a temporary
>> index, and discarded it afterwards, so it doesn't update the stat
>> information in the index (while "git status" would have).
>
> Have you tried "git status" _without_ "-a"?
Reading my message (including the last 5 words of the sentence you're
quoting) would have told you that ;-).
>> In both cases, I can't really see the benefit.
>
> The benefit is a clear distinguishing between DWIM and low level. The
> index contains _exactly_ what you told it to contain.
In other systems, commit commits _exactly_ the content of files on
disk. And most people seem happy with that.
> By forcing users to use "-a" with "git commit",
Does this mean that the normal way to use "commit" is to use "-a"?
> you make it clear that a separate update steo is involved,
Well, with those kind of arguments, I could have my web browser not do
DNS resolution for me, because it would make it clear that a separate
step from HTTP request is involved. Still, this low-level thing brings
no benefit to the user, and I know no web browser forcing the user to
make this distinction.
> and if you made an error (which you see from the file list), you can
> abort, and start over with the original index.
You don't necessarily see your error from the file list:
% vi foo.c
% git add foo.c
% vi foo.c
% git commit -m foo
[...]
create mode 100644 foo.c
%
This commited the old content of foo.c, while I hardly see any
scenario where this is the expected behavior.
Then, being able to repare the error if I made it is interesting, but
I don't get the reason why the error could not just be avoided.
Well, indeed, I just found a thread talking about this:
http://lists-archives.org/git/196050-making-git-commit-to-mean-git-commit-a.html
I'll go through it, I might understand better after that ;-).
Thanks,
--
Matthieu
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Junio C Hamano @ 2007-05-06 17:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dana How, Git Mailing List, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0705061653100.4015@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 5 May 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> >> (a) In a bare repository, I believe
>> >> setup.c:setup_git_directory_gently() determines the prefix to be
>> >> NULL. This means my patch will see ALL paths as absolute, except
>> >> :../path which will result in an error.
>> >
>> > My point was that it feels inconsistent to take the current path into
>> > account in one case, but not in the other.
>>
>> I do not understand your reasoning. In a bare repository you cannot
>> even be in a subdirectory to begin with.
>
> Exactly! That is my point. If you can do it in a working directory, but
> also with a bare repository, I find it highly confusing and inconsistent
> to have different meaning.
Sorry. Now you confused me further. I can do:
cd Documentation
git diff v1.5.0 v1.5.1 -- git.txt
Is that confusing, inconsistent and bad for the users?
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Junio C Hamano @ 2007-05-06 17:43 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqk5vlamav.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> You don't necessarily see your error from the file list:
>
> % vi foo.c
> % git add foo.c
> % vi foo.c
> % git commit -m foo
> [...]
> create mode 100644 foo.c
> %
>
> This commited the old content of foo.c, while I hardly see any
> scenario where this is the expected behavior.
One reason why is because you are using "-m foo" (a very
non-descriptive commit message that would not help anybody
including yourself in the future). Try the above without giving
such a bogus error message with "-m" to commit, but instead let
it spawn your editor --- you would be doing that in real-life
when you are doing anything nontrivial. Then notice what
appears on the file list of "Changed but not updated" section.
A single liner "-m" is handy for "Oops, typofix in foo.c" kind
of commit, but in such a case you literally would be changing
only the typofix and won't have "edit foo.c; git add foo.c; edit
foo.c; git commit" sequence anyway.
I think Linus explained quite well to correct your doubts in
your original message, and I do not have anything to add.
^ permalink raw reply
* [PATCH 1/3] t7300: Basic tests for git-clean
From: Michael Spang @ 2007-05-06 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This tests the -d, -n, -f, -x, and -X options to git-clean.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
---
t/t7300-clean.sh | 157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 157 insertions(+), 0 deletions(-)
create mode 100755 t/t7300-clean.sh
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
new file mode 100755
index 0000000..1fb3850
--- /dev/null
+++ b/t/t7300-clean.sh
@@ -0,0 +1,157 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Michael Spang
+#
+
+test_description='git-clean basic tests'
+
+. ./test-lib.sh
+
+test_expect_success \
+ 'setup' \
+ "mkdir -p src &&
+ touch src/part1.c Makefile &&
+ echo build >> .gitignore &&
+ echo *.o >> .gitignore &&
+ git-add . &&
+ git-commit -m setup &&
+ touch src/part2.c README &&
+ git-add ."
+
+test_expect_success \
+ 'git-clean' \
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test -f docs/manual.txt &&
+ test -f obj.o &&
+ test -f build/lib.so"
+
+test_expect_success \
+ 'git-clean -n' \
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -n &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f a.out &&
+ test -f src/part3.c &&
+ test -f docs/manual.txt &&
+ test -f obj.o &&
+ test -f build/lib.so"
+
+test_expect_success \
+ 'git-clean -d' \
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -d &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test ! -e docs &&
+ test -f obj.o &&
+ test -f build/lib.so"
+
+test_expect_success \
+ 'git-clean -x' \
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -x &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test -f docs/manual.txt &&
+ test ! -e obj.o &&
+ test -f build/lib.so"
+
+test_expect_success \
+ 'git-clean -d -x' \
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -d -x &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test ! -e docs &&
+ test ! -e obj.o &&
+ test ! -e build"
+
+test_expect_success \
+ 'git-clean -X' \
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -X &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f a.out &&
+ test -f src/part3.c &&
+ test -f docs/manual.txt &&
+ test ! -e obj.o &&
+ test -f build/lib.so"
+
+test_expect_success \
+ 'git-clean -d -X' \
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -d -X &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f a.out &&
+ test -f src/part3.c &&
+ test -f docs/manual.txt &&
+ test ! -e obj.o &&
+ test ! -e build"
+
+test_expect_failure \
+ 'clean.requireForce' \
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-config clean.requireForce true &&
+ git-clean"
+
+test_expect_success \
+ 'clean.requireForce and -n' \
+ "test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f a.out &&
+ test -f src/part3.c &&
+ test -f docs/manual.txt &&
+ test -f obj.o &&
+ test -f build/lib.so"
+
+test_expect_success \
+ 'clean.requireForce and -f' \
+ "git-clean -f &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test -f docs/manual.txt &&
+ test -f obj.o &&
+ test -f build/lib.so"
+
+test_done
^ permalink raw reply related
* [PATCH 2/3] dir.c: Omit non-excluded directories with dir->show_ignored
From: Michael Spang @ 2007-05-06 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <463E1705.2090201@gmail.com>
This makes "git-ls-files --others --directory --ignored" behave
as documented and consequently also fixes "git-clean -d -X".
Previously, git-clean would remove non-excluded directories
even when using the -X option.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
---
dir.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/dir.c b/dir.c
index d306352..adb3e62 100644
--- a/dir.c
+++ b/dir.c
@@ -448,6 +448,7 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
while ((de = readdir(fdir)) != NULL) {
int len;
+ int exclude;
if ((de->d_name[0] == '.') &&
(de->d_name[1] == 0 ||
@@ -461,7 +462,7 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
memcpy(fullname + baselen, de->d_name, len+1);
if (simplify_away(fullname, baselen + len, simplify))
continue;
- if (excluded(dir, fullname) != dir->show_ignored) {
+ if ((exclude = excluded(dir, fullname)) != dir->show_ignored) {
if (!dir->show_ignored || DTYPE(de) != DT_DIR) {
continue;
}
@@ -484,6 +485,8 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
len++;
switch (treat_directory(dir, fullname, baselen + len, simplify)) {
case show_directory:
+ if (exclude != dir->show_ignored)
+ continue;
break;
case recurse_into_directory:
contents += read_directory_recursive(dir,
--
1.5.2.rc1.4.g47e1
^ permalink raw reply related
* [PATCH 3/3] Fix minor documentation errors
From: Michael Spang @ 2007-05-06 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <463E1705.2090201@gmail.com>
- git-ls-files.txt: typo in description of --ignored
- git-clean.txt: s/forceRequire/requireForce/
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
---
Documentation/git-clean.txt | 2 +-
Documentation/git-ls-files.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 5aff026..e3252d5 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -26,7 +26,7 @@ OPTIONS
Remove untracked directories in addition to untracked files.
-f::
- If the git configuration specifies clean.forceRequire as true,
+ If the git configuration specifies clean.requireForce as true,
git-clean will refuse to run unless given -f or -n.
-n::
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 79e0b7b..076cebc 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -42,8 +42,8 @@ OPTIONS
Show other files in the output
-i|--ignored::
- Show ignored files in the output
- Note the this also reverses any exclude list present.
+ Show ignored files in the output.
+ Note that this also reverses any exclude list present.
-s|--stage::
Show stage files in the output
^ permalink raw reply related
* [PATCH/RFD 4/3] t7300: Tests for git-clean using filenames with spaces/punctuation
From: Michael Spang @ 2007-05-06 18:09 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <463E1705.2090201@gmail.com>
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
---
This isn't meant for applying, at least until this flaw is fixed.
These tests are failing because ls-files does escaping and clean does
not unescape. Does anyone know of a solution to this?
sed could be used to remove the double quotes and replace escaped characters,
but doing many replacements happens in multiple passes and hence does not
always work as desired.
Is this even properly solvable without making clean a builtin or
writing git-unescape?
t/t7300-clean.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 1fb3850..3792221 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -7,6 +7,8 @@ test_description='git-clean basic tests'
. ./test-lib.sh
+TAB=" "
+
test_expect_success \
'setup' \
"mkdir -p src &&
@@ -123,6 +125,27 @@ test_expect_success \
test ! -e obj.o &&
test ! -e build"
+test_expect_success \
+ 'filenames with spaces' \
+ 'touch abc\ def &&
+ touch 123 123\ &&
+ git-add 123 &&
+ git-clean &&
+ test ! -e abc\ def &&
+ test ! -e 123\ &&
+ test -e 123'
+
+test_expect_success \
+ 'filenames with escaped characters' \
+ 'touch "'"$TAB"'" " " \\ \" \\\\\" \\t &&
+ git-clean &&
+ test ! -e "'"$TAB"'" &&
+ test ! -e " " &&
+ test ! -e \\ &&
+ test ! -e \" &&
+ test ! -e \\\\\" &&
+ test ! -e \\t'
+
test_expect_failure \
'clean.requireForce' \
"mkdir -p build docs &&
^ permalink raw reply related
* Re: [FAQ?] Rationale for git's way to manage the index
From: Dana How @ 2007-05-06 18:22 UTC (permalink / raw)
To: git, Matthieu Moy, danahow
In-Reply-To: <vpqk5vlamav.fsf@bauges.imag.fr>
You might find it useful to break your question into 2 pieces.
One is what information should be in the index,
which essentially is what Linus addresses.
The way I look at this, at the moment,
is that the index contains whatever's required to make git-write-tree
work without collecting information elsewhere.
I suspect this is the correct historical way to look at this,
but I wasn't on this list then.
The other is how to get information into the index.
I think this is the original thing that seemed strange to you?
It did to me. But, in part, since git has both "git-commit"
and "git-commit -a", this is somewhat recognized.
I've wondered if there's a way to improve this, but I don't
have any coherent ideas right now. Thanks for finding
and posting that thread; that was helpful.
Also, the idea of an index isn't all that strange. I need
to use perforce at work, and it has an index (called "db.have").
But it is stored on the server and has everyone's state mixed
together, uses the type of file IDs Linus complains about,
and is more difficult to manipulate (hence less useful).
Being on the server is a great performance bottleneck as well.
Dana
On 5/6/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Sun, 6 May 2007, Matthieu Moy wrote:
> >
> >> [...]
> >>
> >> % git satus -a
> >> % git commit -a -m "..."
> >>
> >> In the former case, I have more commands to type, and in the second
> >> case, I loose part of the stat-cache benefit: If I run "git status -a"
> >> twice, the second run will actually diff all the files touched since
> >> the last run, since "git status -a" actually updated a temporary
> >> index, and discarded it afterwards, so it doesn't update the stat
> >> information in the index (while "git status" would have).
> >
> > Have you tried "git status" _without_ "-a"?
>
> Reading my message (including the last 5 words of the sentence you're
> quoting) would have told you that ;-).
>
> >> In both cases, I can't really see the benefit.
> >
> > The benefit is a clear distinguishing between DWIM and low level. The
> > index contains _exactly_ what you told it to contain.
>
> In other systems, commit commits _exactly_ the content of files on
> disk. And most people seem happy with that.
>
> > By forcing users to use "-a" with "git commit",
>
> Does this mean that the normal way to use "commit" is to use "-a"?
>
> > you make it clear that a separate update steo is involved,
>
> Well, with those kind of arguments, I could have my web browser not do
> DNS resolution for me, because it would make it clear that a separate
> step from HTTP request is involved. Still, this low-level thing brings
> no benefit to the user, and I know no web browser forcing the user to
> make this distinction.
>
> > and if you made an error (which you see from the file list), you can
> > abort, and start over with the original index.
>
> You don't necessarily see your error from the file list:
>
> % vi foo.c
> % git add foo.c
> % vi foo.c
> % git commit -m foo
> [...]
> create mode 100644 foo.c
> %
>
> This commited the old content of foo.c, while I hardly see any
> scenario where this is the expected behavior.
>
> Then, being able to repare the error if I made it is interesting, but
> I don't get the reason why the error could not just be avoided.
>
> Well, indeed, I just found a thread talking about this:
>
> http://lists-archives.org/git/196050-making-git-commit-to-mean-git-commit-a.html
>
> I'll go through it, I might understand better after that ;-).
>
> Thanks,
>
> --
> Matthieu
> -
> 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
>
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Matthieu Moy @ 2007-05-06 18:23 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.98.0705060951460.25245@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 6 May 2007, Matthieu Moy wrote:
>>
>> But the fact that git actually remembers the _content_ of files in the
>> index, and that the default behavior for "commit" is to commit only
>> the content that is explicitely "git add"ed is something I've never
>> seen outside git.
>
> Yeah. You'd better get used to it, because it's fundamental.
Thanks a lot for the detailed explanations.
Note that I'm not "complaining", but just not understanding something.
(I would actually complain about the documentation not being clear
enough, but I'll try to complain with a contribution instead ;-) I'll
add something to the FAQ on the wiki, but it's down right now).
> - You fundamentally cannot do it any other way.
>
> Not doing it the way git does it (point to the content) means that the
> index-replacement has to point to something else, namely a "file ID".
Well, git's index still tells more than "the content FOOBAR exists,
somewhere". It also "contains", if not "points to", the file name.
> What's so hard with adding that "-a" to "git commit"? You don't even need
> it on the status line, the status is relevant and understandable (and
> actually tells you more) even without it.
Off course, I don't have strong argument against it. The biggest
annoyance is that my fingers are used to "commit -m message", and now
type "commit -a message", but ...
The reason why I'm posting this is that I was wondering whether
"commit -a" not being the default was supposed to be a message like
"you shouln't use it too often".
It seems it isn't. I'll just get used to "commit -a" (and probably
alias it), and discover the actual benefits of the index little by
little.
> [...] it basically could be used ass a definition of CVS: [...]
^^^
Not sure this was intentional, but your spelling of "as" when used to
talk about CVS seems to reveal something about your state of mind ;-).
Thanks,
--
Matthieu
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Martin Waitz @ 2007-05-06 18:52 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Shawn O. Pearce, Dana How, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705060259460.4015@racer.site>
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
hoi :)
On Sun, May 06, 2007 at 02:59:55AM +0200, Johannes Schindelin wrote:
> > On Sat, May 05, 2007 at 01:17:35PM -0700, Junio C Hamano wrote:
> > > > we could also introduce "<tree-ish>/<path>" for absolute path entries.
> > >
> > > When you name the tree-ish with usual "branch name", where does
> > > the branch name end and pathname start? What happens when there
> > > is an ambiguity, and how costly to detect such an ambiguity to
> > > begin with?
> >
> > well, if you know that it starts with a tree-ish there is no
> > ambiguity [...]
>
> Wrong. For example, mw/submodules~10 _is_ a tree-ish (if you have a branch
> named "mw/submodules").
so what?
a better argument is that one can have both refs/tags/a and
refs/heads/a/b.
So just forget my suggestion...
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFD 4/3] t7300: Tests for git-clean using filenames with spaces/punctuation
From: Junio C Hamano @ 2007-05-06 18:54 UTC (permalink / raw)
To: Michael Spang; +Cc: Git Mailing List
In-Reply-To: <463E19F6.9000906@uwaterloo.ca>
Michael Spang <mspang@uwaterloo.ca> writes:
> Is this even properly solvable without making clean a builtin or
> writing git-unescape?
If you know how to use "xargs -0" and are willing to depend on
the -0 GNU extension, then the answer is yes.
I do not use git-clean myself, as I do not see what (I think) it
tries to solve as a problem to begin with, so obviously I do not
care too deeply about the command's implementation --- I just
let it be there because there seem to be others who want it ---
but if I were asked an advice on the right direction to proceed,
I would probably suggest rewriting it in C.
^ 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