* Re: What's in git.git
From: Junio C Hamano @ 2006-02-10 15:02 UTC (permalink / raw)
To: Tony Luck; +Cc: git
In-Reply-To: <12c511ca0602091514p35c3904bha8d5d406e5472969@mail.gmail.com>
Tony Luck <tony.luck@intel.com> writes:
> On 2/8/06, Junio C Hamano <junkio@cox.net> wrote:
> [ ... about the "next" branch ... ]
>
> This is pretty much the workflow in my test/release branches (mostly
> documented in Documentation/howto/using-topic-branches.txt).
Yup. Sorry I did not make that clear. You deserve the credit.
I am beginning to feel this workflow might benefit from some
tool support, but I haven't had enough experience to talk about
exactly what they are yet.
For example, listing topics that have ever been merged into a
particular branch, listing topics that have not been fully
merged into a particular branch, etc. are things I find myself
doing frequently. I vaguely recall seeing your post that has
these things.
^ permalink raw reply
* Re: [PATCH] count-delta.c: Match the delta data semantics change in version 3.
From: Nicolas Pitre @ 2006-02-10 15:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602092053200.5397@localhost.localdomain>
On Thu, 9 Feb 2006, Nicolas Pitre wrote:
> On Thu, 9 Feb 2006, Junio C Hamano wrote:
>
> > Junio C Hamano <junkio@cox.net> writes:
> >
> > > The bit is however _already_ looked at by the count_delta(),
> > > to assess the extent of damage, IIRC. Should we be
> > > futureproofing that bit as well?
> >
> > Something like this?
>
> Right.
I'm not sure to fully understand what you meant in the comment below.
but if it was related to the removed code, maybe this patch would make
sense:
diff --git a/count-delta.c b/count-delta.c
index 978a60c..058a2aa 100644
--- a/count-delta.c
+++ b/count-delta.c
@@ -16,11 +16,7 @@
*
* Number of bytes that are _not_ copied from the source is deletion,
* and number of inserted literal bytes are addition, so sum of them
- * is the extent of damage. xdelta can express an edit that copies
- * data inside of the destination which originally came from the
- * source. We do not count that in the following routine, so we are
- * undercounting the source material that remains in the final output
- * that way.
+ * is the extent of damage.
*/
int count_delta(void *delta_buf, unsigned long delta_size,
unsigned long *src_copied, unsigned long *literal_added)
^ permalink raw reply related
* Re: [PATCH] Add git-annotate - a tool for annotating files with the revision and person that created each line in the file.
From: Andreas Ericsson @ 2006-02-10 11:55 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Junio C Hamano, Johannes Schindelin, Franck Bui-Huu, git
In-Reply-To: <20060210112541.GA3513@linux-mips.org>
Ralf Baechle wrote:
> On Wed, Feb 08, 2006 at 11:19:37AM -0800, Junio C Hamano wrote:
>
>
>>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>
>>>>Are there any rules on the choice of the script language ?
>>>
>>>Yes. Do not try to introduce unnecessary dependencies. But if it is
>>>the right tool to do the job, you should use it. As of now, we have perl,
>>>python and Tcl/Tk.
>>
>>Very well said. That's what currently stands.
>
>
> The dependency on Python 2.4 already is a problem for installation on some
> systems ...
>
Not many though. Since Python is only required on the workstation where
the developer does his/her work it's not a very cumbersome requirement.
The same holds for Perl, btw. It's not a requirement on the server
hosting the public repositories, unless some of the scripts are used
from the hooks (git shortlog is used from the default update-hook, but
that can be changed with no trouble at all).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Resetting paths
From: Andreas Ericsson @ 2006-02-10 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkwjzv0w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> While I worked on parts of the system that deals with the cached
> lstat() information, I needed a way to debug that, so I hacked
> ls-files -t option to show entries marked as "always matches the
> index" with lowercase tag letters. This was primarily debugging
> aid hack.
>
> Then I committed the whole thing with "git commit -a" by
> mistake. In order to rewind the HEAD to pre-commit state, I can
> say "git reset --soft HEAD^", but after doing that, now I want
> to unupdate the index so that ls-files.c matches the pre-commit
> HEAD.
>
>
> Have people found themselves in similar need like this? This
> could take different forms.
>
Sometimes, yes.
> * you did "git update-index" on a wrong path. This is my
> example and the above voodoo is a recipe for recovery.
>
> * you did "git add" on a wrong path and you want to remove it.
> This is easier than the above:
>
> git update-index --force-remove path
>
> * you did the above recovery from "git add" on a wrong path,
> and you want to add it again. The same voodoo would work in
> this case as well.
>
> git ls-tree HEAD path | git update-index --index-info
>
> We could add "git reset path..." to reduce typing for the above,
> but I am wondering if it is worth it.
>
How about "git update-index --undo path...", possibly with "git reset
path..." as a shorthand. Support for temporary indexes already exist, so
it should be a simple (and atomic) operation of copying it out with the
paths mentioned skipped, and then overwriting the current index. I'm not
sure how well it would perform on very large repositories, but having a
snappish command to undo a blunder is usually welcome even if it takes
half a minute or more to run.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Add git-annotate - a tool for annotating files with the revision and person that created each line in the file.
From: Ralf Baechle @ 2006-02-10 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Franck Bui-Huu, git
In-Reply-To: <7v3bitr73q.fsf@assigned-by-dhcp.cox.net>
On Wed, Feb 08, 2006 at 11:19:37AM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Are there any rules on the choice of the script language ?
> >
> > Yes. Do not try to introduce unnecessary dependencies. But if it is
> > the right tool to do the job, you should use it. As of now, we have perl,
> > python and Tcl/Tk.
>
> Very well said. That's what currently stands.
The dependency on Python 2.4 already is a problem for installation on some
systems ...
Ralf
^ permalink raw reply
* Re: Tracking and committing back to Subversion?
From: Sam Vilain @ 2006-02-10 11:16 UTC (permalink / raw)
To: Brian Smith; +Cc: git
In-Reply-To: <200602092301.21098.linuxfood@linuxfood.net>
On Thu, 2006-02-09 at 23:01 -0800, Brian Smith wrote:
> > > While that is an admirable goal, unless you can point me to something
> > > that will allow you to actually commit back to SVN without a working
> > > copy,
> > Such as SVK
> > http://svk.elixus.org/
> > (svn url: http://svn.openfoundry.org/svk/)
> Well, after reading through a number of pages I discovered something:
> "The repository created is actually a Subversion repository. In other words,
> you could use any subversion commands with that repository." [*1*]
> So, while it is a technicality, there is an SVN Repo, which is what
> I'm trying to avoid[...
Yes, currently there is - but let me show you what's under the hood
briefly... as you notice later;
> (Incidentally, the allure of the SVN perl bindings had me for awhile, but
> after trying to decipher the horrid PODs for it decided that Bash was just
> easier. )
Yes, there are SWIG bindings for various languages. In debian/ubuntu the
Perl bindings will be built to the package libsvn-core-perl.
Take a look at this module:
http://search.cpan.org/dist/SVN-Simple/lib/SVN/Simple/Edit.pm
That uses the above module and allows you to construct a Subversion
commit and try to apply it.
The documentation's a bit weak, but AFAIK the basic functionality is
there and a lot better an abstraction than the raw bindings themselves.
SVN::Mirror:
http://search.cpan.org/dist/SVN-Mirror/lib/SVN/Mirror.pm
can go the other way.
> (the point being to have a git repo after all, for
> the purpose of using git commands), perhaps it would be worth looking
> into to see if I could somehow utilize the svk svn repo (since there
> are space savings) for the SVN working copy. [*2*]
That's right - in principle, SVK could be plumbed to have a git
repository in its ~/.svk/local - then you could have one git repo, and a
head for each mirrored project.
But don't concern yourself with my plans - it seems our tastes in
porcelain differ ;)
Sam.
^ permalink raw reply
* [PATCH] combine-diff: Record diff status a bit more faithfully
From: Junio C Hamano @ 2006-02-10 11:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vzml08cfm.fsf@assigned-by-dhcp.cox.net>
This shows "new file mode XXXX" and "deleted file mode XXXX"
lines like two-way diff-patch output does, by checking the
status from each parent.
The diff-raw output for combined diff is made a bit uglier by
showing diff status letters with each parent. While most of the
case you would see "MM" in the output, an Evil Merge that
touches a path that was added by inheriting from one parent is
possible and it would be shown like these:
$ git-diff-tree --abbrev -c HEAD
2d7ca89675eb8888b0b88a91102f096d4471f09f
::000000 000000 100644 0000000... 0000000... 31dd686... AA b
::000000 100644 100644 0000000... 6c884ae... c6d4fa8... AM d
::100644 100644 100644 4f7cbe7... f8c295c... 19d5d80... RR e
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I also considered showing the rename detection scores but
felt it was too much information, so refrained from it.
Maybe MM might be too much, but knowing most of the merges
are only two parents' kind, one extra column would not be too
much noise.
By looking at -c -p or --cc output, you cannot tell any
renames, which makes me feel a bit uneasy. I suspect this
is going into purely academic realm and would not be useful
in practice at all, so I'd say we should stop ;-).
combine-diff.c | 32 +++++++++++++++++++++++++-------
diff.h | 1 +
2 files changed, 26 insertions(+), 7 deletions(-)
dc33c79b0f69a1e9acee740a2f7ac5eacfdd49ce
diff --git a/combine-diff.c b/combine-diff.c
index 8ba6949..a38f01b 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -39,6 +39,7 @@ static struct combine_diff_path *interse
p->mode = q->queue[i]->two->mode;
memcpy(p->parent[n].sha1, q->queue[i]->one->sha1, 20);
p->parent[n].mode = q->queue[i]->one->mode;
+ p->parent[n].status = q->queue[i]->status;
*tail = p;
tail = &p->next;
}
@@ -62,6 +63,7 @@ static struct combine_diff_path *interse
memcpy(p->parent[n].sha1,
q->queue[i]->one->sha1, 20);
p->parent[n].mode = q->queue[i]->one->mode;
+ p->parent[n].status = q->queue[i]->status;
break;
}
}
@@ -739,12 +741,25 @@ static int show_patch_diff(struct combin
printf("..%s\n", abb);
if (mode_differs) {
- printf("mode ");
- for (i = 0; i < num_parent; i++) {
- printf("%s%06o", i ? "," : "",
- elem->parent[i].mode);
+ int added = !!elem->mode;
+ for (i = 0; added && i < num_parent; i++)
+ if (elem->parent[i].status !=
+ DIFF_STATUS_ADDED)
+ added = 0;
+ if (added)
+ printf("new file mode %06o", elem->mode);
+ else {
+ if (!elem->mode)
+ printf("deleted file ");
+ printf("mode ");
+ for (i = 0; i < num_parent; i++) {
+ printf("%s%06o", i ? "," : "",
+ elem->parent[i].mode);
+ }
+ if (elem->mode)
+ printf("..%06o", elem->mode);
}
- printf("..%06o\n", elem->mode);
+ putchar('\n');
}
dump_sline(sline, cnt, num_parent);
}
@@ -811,8 +826,11 @@ static void show_raw_diff(struct combine
}
if (opt->output_format == DIFF_FORMAT_RAW ||
- opt->output_format == DIFF_FORMAT_NAME_STATUS)
- printf("%c%c", mod_type, inter_name_termination);
+ opt->output_format == DIFF_FORMAT_NAME_STATUS) {
+ for (i = 0; i < num_parent; i++)
+ putchar(p->parent[i].status);
+ putchar(inter_name_termination);
+ }
if (line_termination) {
if (quote_c_style(p->path, NULL, NULL, 0))
diff --git a/diff.h b/diff.h
index 946a406..8fac465 100644
--- a/diff.h
+++ b/diff.h
@@ -66,6 +66,7 @@ struct combine_diff_path {
unsigned int mode;
unsigned char sha1[20];
struct combine_diff_parent {
+ char status;
unsigned int mode;
unsigned char sha1[20];
} parent[FLEX_ARRAY];
--
1.1.6.g94c6
^ permalink raw reply related
* Re: Two crazy proposals for changing git's diff commands
From: Junio C Hamano @ 2006-02-10 9:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Worth, git
In-Reply-To: <Pine.LNX.4.64.0602081726390.2458@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Under that logic, "git status -v" would show all the diffs (not just
> filenames) and "git commit -v .." would be the same as "git commit .." but
> the "-v" flag would have been passed down to the "git status" call, so the
> commit message file would be pre-populated with the diff.
Now that is done and sitting at the tip of "next".
> For small commits, it's actually nice to see the diff itself as you write
> the commit message.
Yes, that is my experience, and even with fairly big one, it is
pleasant as long as your editor allows you to C-x 2 C-x o around
the file you are editing, like "em" ;-).
commit cf7bb589af739563c90dc32b4901bea73aaaa9d0
Author: Junio C Hamano <junkio@cox.net>
Date: Fri Feb 10 00:45:59 2006 -0800
git-status -v
This revamps the git-status command to take the same set of
parameters as git commit. It gives a preview of what is being
committed with that command. With -v flag, it shows the diff
output between the HEAD commit and the index that would be
committed if these flags were given to git-commit command.
git-commit also acquires -v flag (it used to mean "verify" but
that is the default anyway and there is --no-verify to turn it
off, so not much is lost), which uses the updated git-status -v
to seed the commit log buffer. This is handy for writing a log
message while reviewing the changes one last time.
Now, git-commit and git-status internally share the same
implementation.
Unlike previous git-commit change, this uses a temporary index
to prepare the index file that would become the real index file
after a successful commit, and moves it to the real index file
once the commit is actually made. This makes it safer than the
previous scheme, which stashed away the original index file and
restored it after an aborted commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Documentation
From: Nico -telmich- Schottelius @ 2006-02-10 8:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
Hello!
I wrote some documentation about (using) git in German. For those
interested:
http://nico.schotteli.us/papers/linux/howto/index.html (small introduction)
http://creme.schottelius.org/~nico/linux/arbeiten_mit_git (very short
'how to work with git')
Sincerly,
Nico
--
Latest release: ccollect-0.3.2 (http://linux.schottelius.org/ccollect/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: Tracking and committing back to Subversion?
From: Brian Smith @ 2006-02-10 7:01 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <43EC162E.9090905@vilain.net>
On Thursday 09 February 2006 20:27, Sam Vilain wrote:
>>> [snip]
> >
> > While that is an admirable goal, unless you can point me to something
> > that will allow you to actually commit back to SVN without a working
> > copy,
>
> Such as SVK
>
> http://svk.elixus.org/
> (svn url: http://svn.openfoundry.org/svk/)
Well, after reading through a number of pages I discovered something:
"The repository created is actually a Subversion repository. In other words,
you could use any subversion commands with that repository." [*1*]
So, while it is a technicality, there is an SVN Repo, which is what I'm trying
to avoid (the point being to have a git repo after all, for the purpose of
using git commands), perhaps it would be worth looking into to see if I could
somehow utilize the svk svn repo (since there are space savings) for the SVN
working copy. [*2*]
>
> > [snip]
>
> Your solution may ultimately be the most pragmatic approach. Issues
> surrounding the C (SWIG) bindings between Perl and the Subversion RA
> (remote access) API were "the hard part" in making SVK work, according
> to the lead author.
>
> That being said, I am unaware of any drastic outstanding issues, so
> perhaps there are useful components there.
There are useful things in there. I have considered rewriting in perl so that
I don't have to use my kludge of a rewrite of Getopt::Long (yes, I did. No,
not everything is supported.) but have decided against it mostly because it
would take weeks, and Kosek (my program) isn't even complete yet.
(Incidentally, the allure of the SVN perl bindings had me for awhile, but
after trying to decipher the horrid PODs for it decided that Bash was just
easier. )
>
> > Sure, you can actually pick up the current development straight from
> > git://linuxfood.net/pub/git/kosek.git
>
> I will take a look.
>
Awesome let me know what you think. Please try to ignore the massive lack of
documentation, up until someone in the kopete irc channel showed interest I
had been writing it for my own purposes. Though, since I posted the link here
I did go ahead and fixup the readme with a little howto. If you like it, feel
free to email me with questions and suggestions.
[*1*] http://svk.elixus.org/?SingleUserSVK (under Mapping Repositories)
[*2*]
While writing this, I had an absolutely insane idea, which I may or may not
persue. The idea being that it may be possible to remove 99% of the actual
SVN working copy (except for perhaps the base directory at the root of the
project), and just use symlinks for the rest of the hierarchy. This would
require careful management though, since every .svn directory contains
specific and distinct information.
^ permalink raw reply
* Re: How to pull a single changeset from a child branch into a parent branch?
From: Junio C Hamano @ 2006-02-10 5:01 UTC (permalink / raw)
To: Ben Greear; +Cc: git
In-Reply-To: <43EC10AA.1040800@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> I have a linux-2.6 repo with two branches off of 2.6.13.
>
> One branch (ben_v13) has just my own changes.
> A second branch (work_v13) has the 2.6.13.5 patch, and I've also pulled
> ben_v13 into it.
"2.6.13.5"
o---o---o---o
/ \ "work_v13"
---o "2.6.13" .---*
\ /
o---o---o
"ben_v13"
'o' are commits, '*' is a merge.
> Now, I made a small change to work_v13,
"2.6.13.5"
o---o---o---o
/ \ "work_v13"
---o "2.6.13" .---*---x
\ / (new change)
o---o---o
"ben_v13"
> ... and I'd like to pull only
> that changeset into ben_v13. Is there a way to do that w/out
> having to export and apply a patch?
I would have done things differently.
It is generally a good idea if a change is applicable to more
than one branches, and these branches have merge relationship
between them (work_v13 merges from ben_v13, which has already
happened), then to apply that change to the oldest branch and
pull the branch to the new one. In other words, if you made the
change to 2.6.13 based one, you could have pulled that into
2.6.13.5 based one.
"2.6.13.5"
o---o---o---o
/ \ "work_v13"
---o "2.6.13" .---*
\ /
o---o---o---x
"ben_v13"
(new change)
[Commit what is applicable to both in older branch]
"2.6.13.5"
o---o---o---o
/ \ "work_v13"
---o "2.6.13" .---*--*
\ / /
o---o---o---x---'
"ben_v13"
(new change)
[And then merge that to the derived one]
Assuming that correcting the situation like this is not an
option, you could check "git cherry-pick". It lets you create
something like this:
"2.6.13.5"
o---o---o---o
/ \ "work_v13"
---o "2.6.13" .---*---x
\ /
o---o---o---------x'
"ben_v13" (equivalent of 'x' commit)
The command sequence to do this is:
$ git checkout ben_v13
$ git cherry-pick work_v13
^ permalink raw reply
* Re: [PATCH] ls-files: honour per-directory ignore file from higher directories.
From: Junio C Hamano @ 2006-02-10 4:44 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Sam Ravnborg, git
In-Reply-To: <1139542730.23725.3.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> With this patch, the simplified version of cg-clean passes the cogito
> testsuite. That's where the original bug was caught.
Thanks for testing it.
^ permalink raw reply
* Resetting paths
From: Junio C Hamano @ 2006-02-10 4:40 UTC (permalink / raw)
To: git
While working on "assume unchanged" git series, I found one
thing missing from the current set of tools.
While I worked on parts of the system that deals with the cached
lstat() information, I needed a way to debug that, so I hacked
ls-files -t option to show entries marked as "always matches the
index" with lowercase tag letters. This was primarily debugging
aid hack.
Then I committed the whole thing with "git commit -a" by
mistake. In order to rewind the HEAD to pre-commit state, I can
say "git reset --soft HEAD^", but after doing that, now I want
to unupdate the index so that ls-files.c matches the pre-commit
HEAD.
"git reset --mixed" is a heavy-handed tool for that. It reads
the entier index from the HEAD commit without touching the
working tree, so I would need to add the modified paths back
with "git update-index".
The low-level voodoo to do so for this particular case is this
single liner:
git ls-tree HEAD ls-files.c | git update-index --index-info
Have people found themselves in similar need like this? This
could take different forms.
* you did "git update-index" on a wrong path. This is my
example and the above voodoo is a recipe for recovery.
* you did "git add" on a wrong path and you want to remove it.
This is easier than the above:
git update-index --force-remove path
* you did the above recovery from "git add" on a wrong path,
and you want to add it again. The same voodoo would work in
this case as well.
git ls-tree HEAD path | git update-index --index-info
We could add "git reset path..." to reduce typing for the above,
but I am wondering if it is worth it.
BTW, this shows how "index centric" git is. With other SCM that
has only the last commit and the working tree files, you do not
have to worry any of these things, so it might appear that index
is just a nuisance. But if you do not have any "registry of
paths to be committed", you cannot do a partial commit like what
I did above ("commit changes to all files other than
ls-files.c") without listing all the paths to be committed, or
fall back on CVS style "one path at a time", breaking an atomic
commit, so there is a drawback for not having an index as well.
^ permalink raw reply
* Re: Tracking and committing back to Subversion?
From: Sam Vilain @ 2006-02-10 4:27 UTC (permalink / raw)
To: Brian Smith; +Cc: git
In-Reply-To: <200602091650.55370.linuxfood@linuxfood.net>
Brian Smith wrote:
>>Right; I was looking for an approach that did not require working copies
>>of the remote subversion repository to be kept locally. Still, perhaps
>>that approach has merit, though I would probably start in Perl and use
>>SVK::Simple (see CPAN) to give a richer SVN mirroring API.
> While that is an admirable goal, unless you can point me to something that
> will allow you to actually commit back to SVN without a working copy,
Such as SVK
http://svk.elixus.org/
(svn url: http://svn.openfoundry.org/svk/)
> it
> defeats the purpose of my tools which is basically to use to git for the
> purpose of holding intermediate development before sending it into SVN as a
> final commit. That, and being able to use git tools which speak to me on a
> level far greater than SVN tools. ;)
Your solution may ultimately be the most pragmatic approach. Issues
surrounding the C (SWIG) bindings between Perl and the Subversion RA
(remote access) API were "the hard part" in making SVK work, according
to the lead author.
That being said, I am unaware of any drastic outstanding issues, so
perhaps there are useful components there.
> Sure, you can actually pick up the current development straight from
> git://linuxfood.net/pub/git/kosek.git
I will take a look.
Sam.
^ permalink raw reply
* How to pull a single changeset from a child branch into a parent branch?
From: Ben Greear @ 2006-02-10 4:03 UTC (permalink / raw)
To: git
I have a linux-2.6 repo with two branches off of 2.6.13.
One branch (ben_v13) has just my own changes.
A second branch (work_v13) has the 2.6.13.5 patch, and I've also pulled
ben_v13 into it.
Now, I made a small change to work_v13, and I'd like to pull only
that changeset into ben_v13. Is there a way to do that w/out
having to export and apply a patch?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] ls-files: honour per-directory ignore file from higher directories.
From: Pavel Roskin @ 2006-02-10 3:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Ravnborg, git
In-Reply-To: <7vmzh1eykq.fsf_-_@assigned-by-dhcp.cox.net>
Hello, Junio!
On Thu, 2006-02-09 at 00:16 -0800, Junio C Hamano wrote:
> When git-ls-files -o --exclude-per-directory=.gitignore is run
> from a subdirectory, it did not read from .gitignore from its
> parent directory. Reading from them makes output from these two
> commands consistent:
You beat me at that. Thank you!
With this patch, the simplified version of cg-clean passes the cogito
testsuite. That's where the original bug was caught.
> * If there are positive feedbacks on this one, I consider it
> a safe enough candidate to be included in 1.2.0 release.
Yes, it would be nice to see it released.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Carl Worth @ 2006-02-10 3:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyms0x4p.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
On Thu, 09 Feb 2006 18:24:06 -0800, Junio C Hamano wrote:
> I do not, unfortunately, see much merit in what you have said so
> far, such as renaming "git diff --cached" and "git diff HEAD".
> Running --cached and non --cached against something other than
> HEAD _is_ useful [*1*]
Yes. Of course. My proposed commands still accept a revision
argument, (they just defaulted to HEAD when one was not provided).
> I really feel I should slow down and stop responding for now,
Yeah, me too. I've made enough noise for now. I'll spend more time
using things before proposing anything else, and come back with
something more concrete (== patches) next time instead of just lots of
talk.
Anyway, thanks again for the time. And sorry for the distraction.
No reply necessary from this one. :-)
-Carl
PS. Thanks for the several examples. That's more good training for me,
(the operations here provide a lot of help for things I've always had
to do much more manually with things like CVS). And that's also more
content for tutorials, (and yes, I did mean to sound like I would like
to help generate some of those---I've got some people I'm trying to
convince to switch to git right now, and they'll need some training).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] stat() for existence in safe_create_leading_directories()
From: Junio C Hamano @ 2006-02-10 2:30 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <15788.1139536573@lotus.CS.Berkeley.EDU>
Thanks.
BTW, in an earlier message when I said this:
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> And Junio C Hamano writes:
>
> - Somehow I started to trust your ability to code portably a lot
> - better than I trust myself, [...]
>
> eep. ;) I only have access to three major variations at the
> moment (Linux, semi-old Solaris, recent AIX), so I'm not an
> authority... Solaris 8 is from before the general Linux/glibc
> compatability movement, so it's pretty useful for testing.
I was talking more about competence rather than access to
various environments to test on. I forgot to mention that.
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Junio C Hamano @ 2006-02-10 2:24 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87fymst399.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> The more significant aspect of the above grouping is not "what
> workflow is supported" but whether the commands operate primarily on
> the index or on the files in the working directory. The distinction is
> significant to understanding and taking full advantage of git. And
> this aspect of git is something that is particularly unique to git
> (and hence some source of confusion to newcomers).
I think that is a wrong place to start from. There is no such
thing as "file focused" operation in git. Git _fundamentally_
works with index. The reason "diff-index" without --cached is
there is to tell you what _would_ happen if you were to run
update-index on the path. The same thing for "diff-files". It
tells you what damage you would be inflicting on the index if
you were to update-index it with what you have in the working
tree. They are simulations of what _would_ happen after you
place them in the index, and until you place them in the index
you obviously cannot write things out to a tree.
However much you want to make git pretend to be "file focused",
you cannot deny the fact that the interesting things happen only
after you place things in the index.
Now, from purely traditional SCM point of view, index may be
secondary. People coming from index-less SCM background would
just want two entities: the last checkin and what you have in
the working tree. If your goal is you would want to have an
alternative UI that completely hides index, that is a worthy
goal (I think Cogito attempts to do so and does a reasonably
good job), but that is something different from what git
barebone Porcelains would want to force on its users.
But I do not think that is what you are aiming for in this round
of your proposal.
> I agree. I think the current 'tutorial introduction to git' does a
> good job at demonstrating one work flow. I'm picky though, so the two
> changes I'd like to have in it are: 1) No command-line options
> necessary (rename "commit -a" somehow). 2) Provide an honest
> HEAD->files diff rather than the current "git diff" that just
> 'accidentally' happens to give the same answer in this case.
Again, (2) is "git status -v". Simulation of what would happen
if I were to commit right now. For (1), "git commit" to mean
"git commit -a" has already been rejected, but you could
introduce git-commit-all if you want. I however do not think
that would fly well with general public; after already seeing
100+ commands adding one more would not be too much but I think
that would be an additional confusion, not simplification.
> For a taking-advantage-of-the-index workflow, I think the 'short git
> tutorial' does a poor job, (it makes the index notion just seem
> painful and in the way). But Linus' responses to me in the recent
> threads have helped me understand it better, so there's material for
> an improved tutorial there I think.
Thanks. I take it to mean I can expect some updates to the
section from you ;-).
> Yes, I can do that personally, and I do agree it's a nice benefit of
> git. (Though some might see it as a defect if such scripting is
> perceived as being necessary before getting comfortable use out of the
> tool.)
As I already said, if enough people share the opinon that that
particular wrapper is a good thing, it would become established
BCP and eventually make it into a new command or a new option,
even replacing the existing one if the benefit outweighs the
transition cost.
I do not, unfortunately, see much merit in what you have said so
far, such as renaming "git diff --cached" and "git diff HEAD".
Running --cached and non --cached against something other than
HEAD _is_ useful [*1*], so you cannot remove the existing "git
diff --cached <commit-id>" or "git diff <commit-id>"; which
means you would need two extra command just for the common cases
to run "git diff --cached HEAD" and "git diff HEAD". Certainly
that would be less typing for that particular case, but does
that justify two extra commands? Along with the git-commit-all
that would be three extra commands. I am not convinced.
I really feel I should slow down and stop responding for now,
and instead start spending some time on doing the git-status
updates.
Just so that I do not get misunderstood by the above statement.
I do not mean I will _ignore_ your arguments; what I mean is I
would stop talking, give your thought process time to go all the
way, and then revisit your proposal after you finished thinking.
[Footnote]
*1* Often I find myself doing that while rewriting messy
development history. For example, I start doing some
work without knowing exactly where it leads, and end up with a
history like this:
"master"
o---o
\ "topic"
o---o---o---o---o---o
At this point, "topic" contains something I know I want, but it
contains two concepts that turned out to be completely
independent. And often, one topic component is larger than the
other. It may contain more than two topics.
In order to rewrite this mess to be more manageable, I would
first do "diff master topic", to extract the changes into a
single patch, start picking pieces from it to get logically
self-contained units, and start building on top of "master":
$ git diff master..topic >P.diff
$ git checkout -b topicA master
... pick and apply pieces from P.diff to build
... commits on topicA branch.
o---o---o
/ "topicA"
o---o"master"
\ "topic"
o---o---o---o---o---o
Before doing each commit on "topicA" HEAD, I run "diff HEAD"
before update-index the affected paths, or "diff --cached HEAD"
after. Also I would run "diff --cached master" to make sure
that the changes are only the ones related to "topicA". Usually
I do this for smaller topics first.
After that, I'd do the remainder of the original "topic", but
for that, I do not start from the patchfile I extracted by
comparing "master" and "topic" I used initially. Still on
"topicA", I extract "diff topic", and use it to rebuild the
other topic:
$ git diff -R topic >P.diff ;# --cached also would work fine
$ git checkout -b topicB master
... pick and apply pieces from P.diff to build
... commits on topicB branch.
"topicB"
o---o---o---o---o
/
/o---o---o
|/ "topicA"
o---o"master"
\ "topic"
o---o---o---o---o---o
After I am done, I'd try a pretend-merge between "topicA" and
"topicB" in order to make sure I have not missed anything:
$ git pull . topicA ;# merge it into current "topicB"
$ git diff topic
"topicB"
o---o---o---o---o---* (pretend merge)
/ /
/o---o---o----------'
|/ "topicA"
o---o"master"
\ "topic"
o---o---o---o---o---o
The last diff better not to show anything other than cleanups
for crufts. Then I can finally clean things up:
$ git branch -D topic
$ git reset --hard HEAD^ ;# nuke pretend merge
"topicB"
o---o---o---o---o
/
/o---o---o
|/ "topicA"
o---o"master"
^ permalink raw reply
* [PATCH] stat() for existence in safe_create_leading_directories()
From: Jason Riedy @ 2006-02-10 1:56 UTC (permalink / raw)
To: git
Use stat() to explicitly check for existence rather than
relying on the non-portable EEXIST error in sha1_file.c's
safe_create_leading_directories(). There certainly are
optimizations possible, but then the code becomes almost
the same as that in coreutil's lib/mkdir-p.c.
Other uses of EEXIST seem ok. Tested on Solaris 8, AIX 5.2L,
and a few Linux versions. AIX has some unrelated (I think)
failures right now; I haven't tried many recent gits there.
Anyone have an old Ultrix box to break everything? ;)
Also remove extraneous #includes. Everything's already in
git-compat-util.h, included through cache.h.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
sha1_file.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
597de7026f284d7bb5ea5b929a70b3cf3077e4e7
diff --git a/sha1_file.c b/sha1_file.c
index 20f6419..3d11a9b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -6,8 +6,6 @@
* This handles basic git sha1 object files - packing, unpacking,
* creation etc.
*/
-#include <sys/types.h>
-#include <dirent.h>
#include "cache.h"
#include "delta.h"
#include "pack.h"
@@ -74,6 +72,8 @@ int adjust_shared_perm(const char *path)
int safe_create_leading_directories(char *path)
{
char *pos = path;
+ struct stat st;
+
if (*pos == '/')
pos++;
@@ -82,12 +82,17 @@ int safe_create_leading_directories(char
if (!pos)
break;
*pos = 0;
- if (mkdir(path, 0777) < 0) {
- if (errno != EEXIST) {
+ if (!stat(path, &st)) {
+ /* path exists */
+ if (!S_ISDIR(st.st_mode)) {
*pos = '/';
- return -1;
+ return -3;
}
}
+ else if (mkdir(path, 0777)) {
+ *pos = '/';
+ return -1;
+ }
else if (adjust_shared_perm(path)) {
*pos = '/';
return -2;
--
1.1.5
^ permalink raw reply related
* Re: [PATCH] count-delta.c: Match the delta data semantics change in version 3.
From: Nicolas Pitre @ 2006-02-10 1:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqxg3tdd.fsf_-_@assigned-by-dhcp.cox.net>
On Thu, 9 Feb 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > I agree with the general direction and this futureproofing is a
> > good thing to have before 1.2.0, I think.
> >
> > The bit is however _already_ looked at by the count_delta(),
> > to assess the extent of damage, IIRC. Should we be
> > futureproofing that bit as well?
>
> Something like this?
Right.
Nicolas
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Carl Worth @ 2006-02-10 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr76c5avd.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3774 bytes --]
On Thu, 09 Feb 2006 16:13:42 -0800, Junio C Hamano wrote:
> > Index-lover:
> >
> > update-index
> > diff-index
> > commit-index
> >
> > Index-ignorer:
> >
> > diff-files
> > commit-files
>
> I see where you are coming from and I personally kind of like
> this consistency.
Thanks. I think that means I've described my motivation now. Though I
still have to come up with a valid proposal.
> But I am hesitant to declare these two
> workflows as the _only_ ones officially supported by the tool at
> this moment.
I wouldn't want to do that either. Fortunately, I don't think the
above command set would do anything like that. The workflows above
with the silly names are just examples, but the commands would still
be available in general, and I would expect people to mix and match
for whatever fits best.
The more significant aspect of the above grouping is not "what
workflow is supported" but whether the commands operate primarily on
the index or on the files in the working directory. The distinction is
significant to understanding and taking full advantage of git. And
this aspect of git is something that is particularly unique to git
(and hence some source of confusion to newcomers).
Take a look at how the index vs. files distinction currently plays out
with existing commands:
commit: Acts on index. Can be made to act on files with -a.
diff: Acts between index and files (which is a sort of special case).
Can be made to act on files by passing a tree argument.
Can be made to act on index by passing --cached.
update-index: Acts on index, (as obviously encoded in the name).
> One of our first goals
> would be to have good set of introductory documentations for
> best current practices -- if the project you work on fits this
> workflow, here is a way to do it. With that workflow, there is
> this way.
I agree. I think the current 'tutorial introduction to git' does a
good job at demonstrating one work flow. I'm picky though, so the two
changes I'd like to have in it are: 1) No command-line options
necessary (rename "commit -a" somehow). 2) Provide an honest
HEAD->files diff rather than the current "git diff" that just
'accidentally' happens to give the same answer in this case.
For a taking-advantage-of-the-index workflow, I think the 'short git
tutorial' does a poor job, (it makes the index notion just seem
painful and in the way). But Linus' responses to me in the recent
threads have helped me understand it better, so there's material for
an improved tutorial there I think.
> Sorry, I am not convinced about separate command names, but in
> the meantime you could have small wrappers around "git diff":
> "cw-diff-files" and "cw-diff-index" would be one liner each,
> wouldn't they?
>
> And that is a _good_ thing about git.
Yes, I can do that personally, and I do agree it's a nice benefit of
git. (Though some might see it as a defect if such scripting is
perceived as being necessary before getting comfortable use out of the
tool.)
> And as I said, I do not think "index-lover" and
> "index-ignorer" distinction above would be the only two valid
> workflows anyway, so I feel partitioning the command set along
> those lines is at least premature if not wrong.
Yeah, that's a false partition. People will certainly use commands
from both sets. I think the index-focused vs. files-focused
orientation I've presented here is more valid partition.
And I think if there were a clean files-focused subset of commands
(that also didn't "deny the index" in any fundamental way), that it
would make a good introduction to git, (it would certainly provide a
closer fit to what many people will conceive of as they come from
other systems).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] count-delta.c: Match the delta data semantics change in version 3.
From: Junio C Hamano @ 2006-02-10 1:17 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <7v7j846qco.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I agree with the general direction and this futureproofing is a
> good thing to have before 1.2.0, I think.
>
> The bit is however _already_ looked at by the count_delta(),
> to assess the extent of damage, IIRC. Should we be
> futureproofing that bit as well?
Something like this?
-- >8 --
This matches the count_delta() logic to the change previous
commit introduces to patch_delta().
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
count-delta.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
6cb2807fd27b9e970a9b012b925deab99f480d61
diff --git a/count-delta.c b/count-delta.c
index 7559ff6..978a60c 100644
--- a/count-delta.c
+++ b/count-delta.c
@@ -50,13 +50,10 @@ int count_delta(void *delta_buf, unsigne
if (cmd & 0x08) cp_off |= (*data++ << 24);
if (cmd & 0x10) cp_size = *data++;
if (cmd & 0x20) cp_size |= (*data++ << 8);
+ if (cmd & 0x40) cp_size |= (*data++ << 16);
if (cp_size == 0) cp_size = 0x10000;
- if (cmd & 0x40)
- /* copy from dst */
- ;
- else
- copied_from_source += cp_size;
+ copied_from_source += cp_size;
out += cp_size;
} else {
/* write literal into dst */
--
1.1.6.gce16
^ permalink raw reply related
* Re: Tracking and committing back to Subversion?
From: Brian Smith @ 2006-02-10 1:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6c43ue5.fsf@assigned-by-dhcp.cox.net>
On Thursday 09 February 2006 16:54, Junio C Hamano wrote:
> Brian Smith <linuxfood@linuxfood.net> writes:
> > While that is an admirable goal, unless you can point me to something
> > that will allow you to actually commit back to SVN without a working
> > copy, it defeats the purpose of my tools which is basically to use to git
> > for the purpose of holding intermediate development before sending it
> > into SVN as a final commit.
>
> Wouldn't svk (or svl or whatever it is called these days) be a
> better match for that kind of "keep my work while disconnected
> from master svn repository" purpose?
It would, if it wasn't god awful slow. And besides, AFAIK, it doesn't allow
you to do anything other than keep offline work in a separate SVN repo hosted
on your machine, which means I can't use the git tools.
^ permalink raw reply
* Re: Tracking and committing back to Subversion?
From: Junio C Hamano @ 2006-02-10 0:54 UTC (permalink / raw)
To: Brian Smith; +Cc: git
In-Reply-To: <200602091650.55370.linuxfood@linuxfood.net>
Brian Smith <linuxfood@linuxfood.net> writes:
> While that is an admirable goal, unless you can point me to something that
> will allow you to actually commit back to SVN without a working copy, it
> defeats the purpose of my tools which is basically to use to git for the
> purpose of holding intermediate development before sending it into SVN as a
> final commit.
Wouldn't svk (or svl or whatever it is called these days) be a
better match for that kind of "keep my work while disconnected
from master svn repository" purpose?
^ 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