* Re: What's in git.git
From: Junio C Hamano @ 2006-02-09 10:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43EB1984.3040602@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> This is exactly what I do when I improve upon things in master, and
> according to numerous emails this is the recommended workflow.
Yes.
> Do you mean
> $ git pull git://git.kernel.org/pub/scm/git/git +pu:my-pu
I do mean "+pu:pu". In my illustration, "pu" is used in your
repository to track "pu" retrieved from me, and "my-pu" is a
fork you created from it and you build your changes upon.
$ git pull $URL +pu:my-pu
is a shorthand for:
$ git fetch $URL +pu:my-pu
$ git merge "auto merge message" HEAD my-pu
and you definitely do not want to _fetch_ into my-pu when you
are on my-pu.
> ? Otherwise, I don't see how I can end up with merge-conflicts.
The problem is exactly why you need the plus sign when you fetch,
i.e. "+pu:pu". My "pu" rebases.
Suppose I had this:
o--o--o
/ "pu"
o--o
"master"
You do fetch +pu:pu, branch my-pu, and build on top of it:
o--o--o--o--o--o--o
/ "my-pu"
o--o--o
/ "pu"
o--o
"master"
I add some to my "master" and rebuild "pu", maybe while adding
another commit on "pu". You fetch +pu:pu again:
o--o--o--o--o--o--o
/ "my-pu"
o--o--o o--o--o--o
/ / "pu"
o--o--o--o--o--o--o
"master"
Now, what happens when you merge "pu" into "my-pu"? The three
commits I had on my previous "pu" are not part of the history of
the updated "pu" anymore, but is considered to be part of your
development trail. If these had an addition of a file, and if
your development on top of the previous "pu" modified it, the
merge would result in:
* originally the file did not exist.
* "pu" adds it one way.
* "my-pu" adds it in another way.
This requires a hand merge. What should be done is for me to
instead of rebasing "pu", merge the updated master to "pu".
o--o--o--o--o--o--o
/ "my-pu"
o--o--o--------*--o
/ / "pu"
o--o--o--o--o--o--o
"master"
Then merge between "my-pu" and "pu" become easier. You do not
have to worry about the earlier three commits, because the point
you forked from the previous "pu" becomes the merge base.
The reason I have not done it that way so far is primarily I am
lazy and also I do not like to see too many merges in the log.
Also "pu" tends to have really wacky stuff, so separating out
only usable bits, excluding wacky ones is slightly easier if I
rebuild it from scratch.
The new "next" aka "not too close to bleeding or broken edge"
branch will be managed like the last picture above, in order to
make working with it easier to manage. This is only usable if I
do not include too bleeding-edge topic branch in it.
^ permalink raw reply
* Re: gitweb: View graphes & get tar
From: Bertrand Jacquin @ 2006-02-09 11:12 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200602090003.35354.alan@chandlerfamily.org.uk>
On 2/9/06, Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> On Wednesday 08 February 2006 23:34, Bertrand Jacquin wrote:
> > Hi,
> >
> > Is gitweb maintainer planned to allow people to get from gitweb ? It
> > could be something good for ungited/remote people to get a tar for a
> > specific tree.
> > gd provide to create graphs and is often use in "web project" to
> > generate graphe. Could it here generated a graph of branches like in
> > gitk ?
> > It also could be cool to allow people to get binary files in an other
> > mimetype that text/plain.
> >
> > Here are my wish :D it's worth what it's worth.
>
> You can do some of that a different way.
>
> I have it set up so that when I push a tag into my public git repositories,
> that a post-update hook creates a tarball of the site and puts it into the
> download directory.
>
> The hook is of the following form
>
> #!/bin/sh
> #
> # This script is used to create a tarball of the project and place it into the
> "files"
> # directory of the web site whenever a release is tagged in the repository
> #
> PROJECT=akcmoney
> # this should look at each positional parameter
> for ref ; do
> #if its a tag then create a tarball
> if [ "${ref:0:10}" == "refs/tags/" ] ; then
> git-tar-tree ${ref:10} $PROJECT | gzip -9
> > /var/www/chandlerfamily/files/$PROJECT/$PROJECT-${ref:10}.tar.gz
> fi
> done
That's ok, but with that I couldn't get a tar for _not_ the current
tree. If i want to get a tar tree for 2 months old in not master
branch, I can't with that. The idea here is the create the tar on the
fly, on the user demand.
And also, I use http push so hooks can't be used :/
>
> --
> Alan Chandler
> http://www.chandlerfamily.org.uk
> Open Source. It's the difference between trust and antitrust.
> -
> 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
>
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: gitweb: View graphes & get tar
From: Sven Verdoolaege @ 2006-02-09 11:18 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: git
In-Reply-To: <4fb292fa0602081534x7f6e74c1veb8c4ea7ad5a83cc@mail.gmail.com>
On Thu, Feb 09, 2006 at 12:34:43AM +0100, Bertrand Jacquin wrote:
> Hi,
>
> Is gitweb maintainer planned to allow people to get from gitweb ? It
> could be something good for ungited/remote people to get a tar for a
> specific tree.
I have something like that in my gitweb tree
(http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary)
I haven't updated it for a while, though...
I usually get a lot of merge conflicts when Kay changes
a particular line that appear about a hundred times in his version and
only once in my version...
skimo
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-02-09 11:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfymsddqo.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 9 Feb 2006, Junio C Hamano wrote:
> Branches are cheap from the storage point of view (not really,
> one inode and a filesystem block wasted to store only 41-bytes
> ;-)), [...]
Not really. I use reiserfs which is quite efficient on these small files.
Hth,
Dscho
^ permalink raw reply
* Re: What's in git.git
From: Andreas Ericsson @ 2006-02-09 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr76cby2v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> The problem is exactly why you need the plus sign when you fetch,
> i.e. "+pu:pu". My "pu" rebases.
>
> Suppose I had this:
>
> o--o--o
> / "pu"
> o--o
> "master"
>
> You do fetch +pu:pu, branch my-pu, and build on top of it:
>
> o--o--o--o--o--o--o
> / "my-pu"
> o--o--o
> / "pu"
> o--o
> "master"
>
> I add some to my "master" and rebuild "pu", maybe while adding
> another commit on "pu". You fetch +pu:pu again:
>
> o--o--o--o--o--o--o
> / "my-pu"
> o--o--o o--o--o--o
> / / "pu"
> o--o--o--o--o--o--o
> "master"
>
But wouldn't rebase detect the commits as being the same, unless you've
made changes to them? If it doesn't, can we teach it to discard parent
info and re-hash the commits if they conflict? That should solve most
such merge-conflicts, really.
> Now, what happens when you merge "pu" into "my-pu"? The three
> commits I had on my previous "pu" are not part of the history of
> the updated "pu" anymore, but is considered to be part of your
> development trail. If these had an addition of a file, and if
> your development on top of the previous "pu" modified it, the
> merge would result in:
>
> * originally the file did not exist.
> * "pu" adds it one way.
> * "my-pu" adds it in another way.
>
> This requires a hand merge. What should be done is for me to
> instead of rebasing "pu", merge the updated master to "pu".
>
> o--o--o--o--o--o--o
> / "my-pu"
> o--o--o--------*--o
> / / "pu"
> o--o--o--o--o--o--o
> "master"
>
> Then merge between "my-pu" and "pu" become easier. You do not
> have to worry about the earlier three commits, because the point
> you forked from the previous "pu" becomes the merge base.
>
> The reason I have not done it that way so far is primarily I am
> lazy and also I do not like to see too many merges in the log.
> Also "pu" tends to have really wacky stuff, so separating out
> only usable bits, excluding wacky ones is slightly easier if I
> rebuild it from scratch.
>
> The new "next" aka "not too close to bleeding or broken edge"
> branch will be managed like the last picture above, in order to
> make working with it easier to manage. This is only usable if I
> do not include too bleeding-edge topic branch in it.
>
>
Good thinking. You're a marvel at explaining things.
--
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: Franck Bui-Huu @ 2006-02-09 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vek2cetxh.fsf@assigned-by-dhcp.cox.net>
2006/2/9, Junio C Hamano <junkio@cox.net>:
> Andreas Ericsson <ae@op5.se> writes:
>
> > So long as we never involve ruby, java or DCL, I'm a happy fellow.
>
> Wholeheartedly seconded ;-).
>
I agree to but my point was more why not only using python scripts ?
Why sometimes some scripts is written in perl whereas python could be
used and vice-versa ?
Thanks
--
Franck
^ permalink raw reply
* Re: gitweb: View graphes & get tar
From: Andreas Ericsson @ 2006-02-09 12:11 UTC (permalink / raw)
To: git
In-Reply-To: <4fb292fa0602090312k1607e42fu88e03b788d339390@mail.gmail.com>
Bertrand Jacquin wrote:
> On 2/9/06, Alan Chandler <alan@chandlerfamily.org.uk> wrote:
>
>>On Wednesday 08 February 2006 23:34, Bertrand Jacquin wrote:
>>
>>
>>I have it set up so that when I push a tag into my public git repositories,
>>that a post-update hook creates a tarball of the site and puts it into the
>>download directory.
>>
>>The hook is of the following form
>>
>>#!/bin/sh
>>#
>># This script is used to create a tarball of the project and place it into the
>>"files"
>># directory of the web site whenever a release is tagged in the repository
>>#
>>PROJECT=akcmoney
>># this should look at each positional parameter
>>for ref ; do
>>#if its a tag then create a tarball
>> if [ "${ref:0:10}" == "refs/tags/" ] ; then
>> git-tar-tree ${ref:10} $PROJECT | gzip -9
>>
>>>/var/www/chandlerfamily/files/$PROJECT/$PROJECT-${ref:10}.tar.gz
>>
>> fi
>>done
>
>
> That's ok, but with that I couldn't get a tar for _not_ the current
> tree. If i want to get a tar tree for 2 months old in not master
> branch, I can't with that. The idea here is the create the tar on the
> fly, on the user demand.
This should be really trivial to implement, although I seriously doubt
its usefulness, not to mention that for large projects it would be
painfully slow. The only valid reason someone has to get a tar-ball of a
random development point is to debug it, and for that they should check
out the whole repo anyways, which will enable them to use the excellent
bisect tool.
> And also, I use http push so hooks can't be used :/
>
I suffer for you.
--
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: Andreas Ericsson @ 2006-02-09 12:47 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Junio C Hamano, git
In-Reply-To: <cda58cb80602090404o4e753839g@mail.gmail.com>
Franck Bui-Huu wrote:
> 2006/2/9, Junio C Hamano <junkio@cox.net>:
>
>>Andreas Ericsson <ae@op5.se> writes:
>>
>>
>>>So long as we never involve ruby, java or DCL, I'm a happy fellow.
>>
>>Wholeheartedly seconded ;-).
>>
>
>
> I agree to but my point was more why not only using python scripts ?
> Why sometimes some scripts is written in perl whereas python could be
> used and vice-versa ?
>
Perl is better suited for some tasks, Python for others. Mostly it's
because the contributor (one out of 137 to date) thought the language
appropriate for the tool he/she set out to write and felt comfortable
with it.
I personally abhor the syntax of Perl and the block indentation of
Python but I happily embrace both if the alternative is to rewrite all
the script tools in C.
That said, some tools have been rewritten in the past (mostly scripts
have been replaced by C code versions), but I don't think Junio will
accept replacement tools just because they're in one particular
language. If anything, it would be to replace the two python scripts
with Perl versions, since more tools are implemented in Perl than in
Python (so we could drop one dependency), Perl exists on more platforms
(so git becomes more portable), and Perl is used inline in four of the
shell-scripts (which means we can't get rid of the Perl dependency
without major hackery anyway).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Add --diff-filter= documentation paragraph
From: Jon Loeliger @ 2006-02-09 15:12 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
----
So, I don't know what the "*" selection flag does.
It is called "AON" in the source. Anyone?
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 5c85167..e00dd6c 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -35,6 +35,13 @@
-C::
Detect copies as well as renames.
+--diff-filter=[ACDMRTUX*B]::
+ Select only files that are Added (A), Copied (C), Deleted (D),
+ Modified (M), Renamed (R), have their Type (mode) changed,
+ are Unmerged (U), are Unknown (X), are "AON" (*),
+ or have had their pairing Broken (B). Any combination of
+ the filter characters may be used.
+
--find-copies-harder::
For performance reasons, by default, -C option finds copies only
if the original file of the copy was modified in the same
^ permalink raw reply related
* Re: gitweb using "--cc"?
From: Linus Torvalds @ 2006-02-09 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0b9jkad.fsf@assigned-by-dhcp.cox.net>
On Wed, 8 Feb 2006, Junio C Hamano wrote:
>
> True. There was a discussion to come up with a sensible
> semantics for -c without -p (currently --cc and -c implies -p),
> but I haven't got around to it, since --cc was more useful in
> general.
>
> Volunteers?
This is a first try at it.
NOTE! This makes "-c" be the default, which effectively means that merges
are never ignored any more, and "-m" is a no-op. So it changes semantics.
I would also like to make "--cc" the default if you do patches, but didn't
actually do that.
The raw output format is not wonderfully pretty, but it's distinguishable
from a "normal patch" in that a normal patch with just one parent has just
one colon at the beginning, while a multi-parent raw diff has <n> colons
for <n> parents.
So now, in the kernel, when you do
git-diff-tree cce0cac125623f9b68f25dd1350f6d616220a8dd
(to see the manual ARM merge that had a conflict in arch/arm/Kconfig), you
get
cce0cac125623f9b68f25dd1350f6d616220a8dd
::100644 100644 100644 4a63a8e2e45247a11c068c6ed66c6e7aba29ddd9 77eee38762d69d3de95ae45dd9278df9b8225e2c 2f61726d2f4b636f6e66696700dbf71a59dad287 arch/arm/Kconfig
ie you see two colons (two parents), then three modes (parent modes
followed by result mode), then three sha1s (parent sha1s followed by
result sha1).
Which is pretty close to the normal raw diff output.
NOTE! There are a few known issues:
- a normal raw output will also do the "what happened" status character.
I didn't. I'm stupid and lazy. It's not strictly needed (since it's
obvious from the multiple colons), but I suspect we should do
something to perhaps clarify what it is. Or just put "M" for "modified
in merge")
- It doesn't honor the "EOL" character, so "git-diff-tree -z" does the
wrong thing. Gaah. I should have just passed down the whole
"diff_options" instead of just the format. I'm a retard.
but it's a beginning..
Linus
---
diff --git a/combine-diff.c b/combine-diff.c
index 6a9f368..935ba2a 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -776,8 +776,35 @@ int show_combined_diff(struct combine_di
return shown_header;
}
+#define COLONS "::::::::::::::::::::::::::::::::"
+
+static void show_raw_diff(struct combine_diff_path *p, int num_parent, const char *header)
+{
+ int i, offset;
+ const char *prefix;
+
+ if (header)
+ puts(header);
+ offset = strlen(COLONS) - num_parent;
+ if (offset < 0)
+ offset = 0;
+ prefix = COLONS + offset;
+
+ /* Show the modes */
+ for (i = 0; i < num_parent; i++) {
+ printf("%s%06o", prefix, p->parent[i].mode);
+ prefix = " ";
+ }
+ printf("%s%06o", prefix, p->mode);
+ for (i = 0; i < num_parent; i++) {
+ printf("%s%s", prefix, sha1_to_hex(p->parent[i].sha1));
+ prefix = " ";
+ }
+ printf("%s%s\t%s\n", prefix, sha1_to_hex(p->parent[i].sha1), p->path);
+}
+
int diff_tree_combined_merge(const unsigned char *sha1,
- const char *header, int dense)
+ const char *header, int dense, int format)
{
struct commit *commit = lookup_commit(sha1);
struct diff_options diffopts;
@@ -815,6 +842,11 @@ int diff_tree_combined_merge(const unsig
for (p = paths; p; p = p->next) {
if (!p->len)
continue;
+ if (format == DIFF_FORMAT_RAW) {
+ show_raw_diff(p, num_parent, header);
+ header = NULL;
+ continue;
+ }
if (show_combined_diff(p, num_parent, dense, header))
header = NULL;
}
diff --git a/diff-tree.c b/diff-tree.c
index 7148323..78bce06 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -6,7 +6,7 @@ static int show_root_diff = 0;
static int no_commit_id = 0;
static int verbose_header = 0;
static int ignore_merges = 1;
-static int combine_merges = 0;
+static int combine_merges = 1;
static int dense_combined_merges = 0;
static int read_stdin = 0;
static int always_show_header = 0;
@@ -118,7 +118,8 @@ static int diff_tree_commit(struct commi
else if (combine_merges) {
header = generate_header(sha1, sha1, commit);
return diff_tree_combined_merge(sha1, header,
- dense_combined_merges);
+ dense_combined_merges,
+ diff_options.output_format);
}
}
@@ -285,10 +286,12 @@ int main(int argc, const char **argv)
usage(diff_tree_usage);
}
- if (combine_merges) {
- diff_options.output_format = DIFF_FORMAT_PATCH;
+ if (combine_merges)
ignore_merges = 0;
- }
+
+ /* We can only do dense combined merges with diff output */
+ if (dense_combined_merges)
+ diff_options.output_format = DIFF_FORMAT_PATCH;
if (diff_options.output_format == DIFF_FORMAT_PATCH)
diff_options.recursive = 1;
diff --git a/diff.h b/diff.h
index 5c5e7fa..f7b3d2a 100644
--- a/diff.h
+++ b/diff.h
@@ -77,7 +77,7 @@ struct combine_diff_path {
int show_combined_diff(struct combine_diff_path *elem, int num_parent,
int dense, const char *header);
-extern int diff_tree_combined_merge(const unsigned char *sha1, const char *, int);
+extern int diff_tree_combined_merge(const unsigned char *sha1, const char *, int, int);
extern void diff_addremove(struct diff_options *,
int addremove,
^ permalink raw reply related
* Re: gitweb using "--cc"?
From: Linus Torvalds @ 2006-02-09 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602090822100.2458@g5.osdl.org>
On Thu, 9 Feb 2006, Linus Torvalds wrote:
>
> This is a first try at it.
Btw, if it wasn't clear, this patch _does_ fix the fact that
"git-whatchanged" didn't show merges even if they have conflicts.
Of course, since the raw format is equivalent to "-c" and only bases its
"should I show" logic on whether the file has changed at all, it very
fundamentally will never be able to tell the difference between a real
content conflict and something that just had file-level automatic merging.
So "git-whatchanged" will now show a lot of merges that didn't really
change anything, but that just merged on a file level (ie the whole merge
just goes away when you specify "--cc").
Still, that's actually interesting information too, so you can consider
this a feature.
Linus
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Tim Larson @ 2006-02-09 16:44 UTC (permalink / raw)
To: git
In-Reply-To: <87slqtcr2f.wl%cworth@cworth.org>
Reading bits an pieces of your email gives an idea:
[...given at the end of this email]
On Wed, Feb 08, 2006 at 04:29:44PM -0800, Carl Worth wrote:
> So, here I am as a newly converted index-embracer---no more index
> denying from me.
>
> However, I'm still trying to wrap my brain around the various diff
> commands that git provides and how they would fit into my workflow,
> Junio and I have touched on this already in a previous thread, but I'm
> starting here with more fresh and complete analysis of the UI around
> diff.
...
> [*] It's not the original topic of this post, but now that I've
> finished this, I realize that if the diff proposal were implemented
> then "commit-files" would make a dandy replacement for "commit
> -a". That could lead to finally providing the parallel preview
> commands I originally wanted:
>
> git diff-index # as preview for
> git commit-index
> and:
> git diff-files # as preview for
> git commit-files
>
> Then "git commit" would just be a shortcut for git commit-index.
>
> (Oh, and that would also lead to a natural "git ci" abbreviation too,
> if desired. This would parallel the "ci == checkin" abbreviation that
> some other systems provide.)
>
> I think the separate notions of commit-index and commit-files would do
> a good job of allowing for simple tutorials, (eliminates the "what the
> heck is -a all about?" questions), that also don't contribute to
> general index-unawareness lead to later index-confusion as the current
> "git diff; git commit -a" does.
>
> This might even lead to a natural distinction between "git
> status-index" and "git status files" too.
...and now the idea:
What if we leave the normal long commands alone, so scripts and
muscle memory are not disturbed, but create some short commands
that give intuitive true parallel previews:
"git di" and "git ci" (diff or commit index)
"git df" and "git cf" (diff or commit files)
"git dm" and "git cm" (diff or commit merge)
and of course any other little bits as needed like:
"git si", "git sf", etc. (status index, status file, etc.)
This would give a chance to "start over" with clear commands,
without causing a ruckus among existing loyal users. WDYT?
--Tim Larson
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Linus Torvalds @ 2006-02-09 18:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602090822100.2458@g5.osdl.org>
[ Apologies if this comes several times. I had a few failed attempts ]
On Thu, 9 Feb 2006, Linus Torvalds wrote:
>
> NOTE! There are a few known issues:
>
> - a normal raw output will also do the "what happened" status character.
> I didn't. I'm stupid and lazy. It's not strictly needed (since it's
> obvious from the multiple colons), but I suspect we should do
> something to perhaps clarify what it is. Or just put "M" for "modified
> in merge")
>
> - It doesn't honor the "EOL" character, so "git-diff-tree -z" does the
> wrong thing. Gaah. I should have just passed down the whole
> "diff_options" instead of just the format. I'm a retard.
A few more:
- it doesn't honor "--abbrev", which it really should
- git-diff-tree doesn't do the right thing for "header_prefix".
Anyway, this updated patch (throw the old one away) should fix all these
issues.
Cool/stupid exercise:
git-whatchanged | grep '^::' | cut -f2- | sort | uniq -c | sort -n | less -S
will show which files have needed the most file-level merge conflict
resolution. Useful? Probably not. But kind of interesting (for the kernel,
it's
....
10 arch/ia64/Kconfig
11 drivers/scsi/Kconfig
12 drivers/net/Makefile
17 include/linux/libata.h
18 include/linux/pci_ids.h
23 drivers/net/Kconfig
24 drivers/scsi/libata-scsi.c
28 drivers/scsi/libata-core.c
43 MAINTAINERS
in case anybody cares).
Linus
---
diff --git a/combine-diff.c b/combine-diff.c
index 6a9f368..15f369e 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -776,8 +776,52 @@ int show_combined_diff(struct combine_di
return shown_header;
}
-int diff_tree_combined_merge(const unsigned char *sha1,
- const char *header, int dense)
+#define COLONS "::::::::::::::::::::::::::::::::"
+
+static void show_raw_diff(struct combine_diff_path *p, int num_parent, const char *header, struct diff_options *opt)
+{
+ int i, offset, mod_type = 'A';
+ const char *prefix;
+ int line_termination, inter_name_termination;
+
+ line_termination = opt->line_termination;
+ inter_name_termination = '\t';
+ if (!line_termination)
+ inter_name_termination = 0;
+
+ if (header)
+ puts(header);
+ offset = strlen(COLONS) - num_parent;
+ if (offset < 0)
+ offset = 0;
+ prefix = COLONS + offset;
+
+ /* Show the modes */
+ for (i = 0; i < num_parent; i++) {
+ int mode = p->parent[i].mode;
+ if (mode)
+ mod_type = 'M';
+ printf("%s%06o", prefix, mode);
+ prefix = " ";
+ }
+ printf("%s%06o", prefix, p->mode);
+ if (!p->mode)
+ mod_type = 'D';
+
+ /* Show sha1's */
+ for (i = 0; i < num_parent; i++) {
+ printf("%s%s", prefix, diff_unique_abbrev(p->parent[i].sha1, opt->abbrev));
+ prefix = " ";
+ }
+ printf("%s%s", prefix, diff_unique_abbrev(p->sha1, opt->abbrev));
+
+ /* Modification type, terminations, filename */
+ printf(" %c%c%s%c", mod_type, inter_name_termination, p->path, line_termination);
+}
+
+const char *diff_tree_combined_merge(const unsigned char *sha1,
+ const char *header, int dense,
+ struct diff_options *opt)
{
struct commit *commit = lookup_commit(sha1);
struct diff_options diffopts;
@@ -815,6 +859,11 @@ int diff_tree_combined_merge(const unsig
for (p = paths; p; p = p->next) {
if (!p->len)
continue;
+ if (opt->output_format == DIFF_FORMAT_RAW) {
+ show_raw_diff(p, num_parent, header, opt);
+ header = NULL;
+ continue;
+ }
if (show_combined_diff(p, num_parent, dense, header))
header = NULL;
}
@@ -826,5 +875,5 @@ int diff_tree_combined_merge(const unsig
paths = paths->next;
free(tmp);
}
- return 0;
+ return header;
}
diff --git a/diff-tree.c b/diff-tree.c
index 7148323..df6fd97 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -6,7 +6,7 @@ static int show_root_diff = 0;
static int no_commit_id = 0;
static int verbose_header = 0;
static int ignore_merges = 1;
-static int combine_merges = 0;
+static int combine_merges = 1;
static int dense_combined_merges = 0;
static int read_stdin = 0;
static int always_show_header = 0;
@@ -117,8 +117,12 @@ static int diff_tree_commit(struct commi
return 0;
else if (combine_merges) {
header = generate_header(sha1, sha1, commit);
- return diff_tree_combined_merge(sha1, header,
- dense_combined_merges);
+ header = diff_tree_combined_merge(sha1, header,
+ dense_combined_merges,
+ &diff_options);
+ if (!header && verbose_header)
+ header_prefix = "\ndiff-tree ";
+ return 0;
}
}
@@ -285,10 +289,12 @@ int main(int argc, const char **argv)
usage(diff_tree_usage);
}
- if (combine_merges) {
- diff_options.output_format = DIFF_FORMAT_PATCH;
+ if (combine_merges)
ignore_merges = 0;
- }
+
+ /* We can only do dense combined merges with diff output */
+ if (dense_combined_merges)
+ diff_options.output_format = DIFF_FORMAT_PATCH;
if (diff_options.output_format == DIFF_FORMAT_PATCH)
diff_options.recursive = 1;
diff --git a/diff.h b/diff.h
index 5c5e7fa..9088519 100644
--- a/diff.h
+++ b/diff.h
@@ -74,10 +74,10 @@ struct combine_diff_path {
(sizeof(struct combine_diff_path) + \
sizeof(struct combine_diff_parent) * (n) + (l) + 1)
-int show_combined_diff(struct combine_diff_path *elem, int num_parent,
- int dense, const char *header);
+extern int show_combined_diff(struct combine_diff_path *elem, int num_parent,
+ int dense, const char *header);
-extern int diff_tree_combined_merge(const unsigned char *sha1, const char *, int);
+extern const char *diff_tree_combined_merge(const unsigned char *sha1, const char *, int, struct diff_options *opt);
extern void diff_addremove(struct diff_options *,
int addremove,
^ permalink raw reply related
* Fatal error from git bisect
From: Mark E Mason @ 2006-02-09 18:51 UTC (permalink / raw)
To: git; +Cc: Mark E Mason
Hello,
I'm trying to use 'git bisect' and am running into the following error:
[mason@hawaii linux.git]$ git bisect reset
[mason@hawaii linux.git]$ git bisect start
[mason@hawaii linux.git]$ git bisect good
d166b5a220813a08a79312fc384d11e1c57e9072
[mason@hawaii linux.git]$ git bisect bad
a7900c9bdb64c11688719bef9f6373fbc4c276ab
Bisecting: 116 revisions left to test after this
fatal: Entry 'block/elevator.c' would be overwritten by merge. Cannot
merge.
(this is the linux-mips.org kernel repository, a7900c9b is a child of
d166b5a2).
What does this mean? How do I get around it?
As you can probably guess, I'm a beginner to git bisect.
Thanks in advance.
Mark
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-09 19:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602091029310.2458@g5.osdl.org>
I was wondering if we could teach not diff_tree_combined_merge
but show_combined_diff to do this, so that diff-files -c would
benefit from the raw output as wel.
That aside, one remaining nit with your patch is printing
p->path. diff.c::diff_flush_raw() does something like this:
if (line_termination) {
path_one = quote_one(path_one);
path_two = quote_one(path_two);
}
...
printf("%s%c%s", status, inter_name_termination, path_one);
But otherwise from a cursory look the patch appears correct.
Thanks.
^ permalink raw reply
* Re: Fatal error from git bisect
From: Linus Torvalds @ 2006-02-09 19:50 UTC (permalink / raw)
To: Mark E Mason; +Cc: git
In-Reply-To: <7E000E7F06B05C49BDBB769ADAF44D0773A48E@NT-SJCA-0750.brcm.ad.broadcom.com>
On Thu, 9 Feb 2006, Mark E Mason wrote:
>
> I'm trying to use 'git bisect' and am running into the following error:
>
> fatal: Entry 'block/elevator.c' would be overwritten by merge. Cannot merge.
This seems to mean that you have a dirty block/elevator.c file. Have you
perhaps edited it?
Linus
^ permalink raw reply
* Re: [PATCH] Add --diff-filter= documentation paragraph
From: Junio C Hamano @ 2006-02-09 19:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1F7DSt-0001q8-PV@jdl.com>
Jon Loeliger <jdl@jdl.com> writes:
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
>
> ----
>
> So, I don't know what the "*" selection flag does.
> It is called "AON" in the source. Anyone?
That's All-or-None.
After applying the other filters if there is anything left, then
spit out everything (including the ones that did not pass the
other filters). Otherwise do not output anything.
In other words,
-M --pretty --diff-filter='R'
shows log for a commit that contains a rename, and diff for only
renamed paths. On the other hand,
-M --pretty --diff-filter='R*'
shows the same log and diff for all paths the commit touches,
not just the renamed ones.
^ permalink raw reply
* RE: Fatal error from git bisect
From: Mark E Mason @ 2006-02-09 19:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Hello!
> From: Linus Torvalds [mailto:torvalds@osdl.org]
[snip]
> On Thu, 9 Feb 2006, Mark E Mason wrote:
> >
> > I'm trying to use 'git bisect' and am running into the
> following error:
> >
> > fatal: Entry 'block/elevator.c' would be overwritten by
> merge. Cannot merge.
>
> This seems to mean that you have a dirty block/elevator.c
> file. Have you perhaps edited it?
I thought of that, but even removing the workspace file doesn't get
around this:
[mason@hawaii linux.git]$ git bisect reset
[mason@hawaii linux.git]$ git bisect start
[mason@hawaii linux.git]$ git bisect good
d166b5a220813a08a79312fc384d11e1c57e9072
[mason@hawaii linux.git]$ git bisect bad
a7900c9bdb64c11688719bef9f6373fbc4c276ab
Bisecting: 116 revisions left to test after this
fatal: Entry 'block/elevator.c' would be overwritten by merge. Cannot
merge.
[mason@hawaii linux.git]$ rm block/elevator.c
[mason@hawaii linux.git]$ git bisect bad
a7900c9bdb64c11688719bef9f6373fbc4c276ab
Bisecting: 116 revisions left to test after this
fatal: Entry 'block/elevator.c' would be overwritten by merge. Cannot
merge.
I've made no commits to this tree - it's just an up-to-date pull of the
linux-mips.org tree. I also have no local edits at this point.
[mason@hawaii linux.git]$ git diff
[mason@hawaii linux.git]$
What's puzzling me is that (as I understand it) git bisect simply
manipulates the workspace, not the repository.
Thanks!
Mark
^ permalink raw reply
* RE: Fatal error from git bisect
From: Linus Torvalds @ 2006-02-09 20:16 UTC (permalink / raw)
To: Mark E Mason; +Cc: git
In-Reply-To: <7E000E7F06B05C49BDBB769ADAF44D0773A4A8@NT-SJCA-0750.brcm.ad.broadcom.com>
On Thu, 9 Feb 2006, Mark E Mason wrote:
>
> I thought of that, but even removing the workspace file doesn't get
> around this:
That doesn't necessarily help. Removing the workspace file potentially
just makes the workspace even _more_ dirty, rather than less. It makes git
think you've edited the file that it wants to check out another verion of.
(Of course, an extra file can _also_ be a sign of being dirty, so
sometimes removing such a file _does_ generate a "more clean" tree).
Basically, "dirty" means that it doesn't match the head commit.
> I've made no commits to this tree - it's just an up-to-date pull of the
> linux-mips.org tree. I also have no local edits at this point.
>
> [mason@hawaii linux.git]$ git diff
> [mason@hawaii linux.git]$
>
> What's puzzling me is that (as I understand it) git bisect simply
> manipulates the workspace, not the repository.
Well, it doesn't _change_ the repository, but it does move around in it,
using "git-read-tree -u -m". That can error out if the old tree and the
new tree differs in a particular file, and the workspace doesn't match the
old tree in that file.
Now, it could be a git bug, but before you go there, try to make sure tat
your tree is really clean. Do a
git checkout -f master
followed by "git status" to make sure that the workspace is clean (no
unexpected untracked files, no diffs against HEAD, no nothing). The "git
checkout -f master" should have cleaned everything up, but it won't
actually touch extra files that it doesn't know about, so..
Linus
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Linus Torvalds @ 2006-02-09 20:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v3bisb9qn.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Feb 2006, Junio C Hamano wrote:
>
> I was wondering if we could teach not diff_tree_combined_merge
> but show_combined_diff to do this, so that diff-files -c would
> benefit from the raw output as wel.
I wanted to do it that way, but it seemed less intrusive this way.
I agree that it is the correct thing to do, though.
> That aside, one remaining nit with your patch is printing
> p->path. diff.c::diff_flush_raw() does something like this:
>
> if (line_termination) {
> path_one = quote_one(path_one);
> path_two = quote_one(path_two);
> }
> ...
> printf("%s%c%s", status, inter_name_termination, path_one);
Good point.
I found another nitpick: file removal doesn't seem to generate a good
diff in "git-diff-tree --cc" (but it's correct in the new "raw" format
diff).
Here's a test-case, in case you care. Do "git-diff-tree --cc HEAD" in the
merge-test directory.
Finally, I think it would be good to have a "--ignore-mode" flag that
drops the mode info from the raw format (that repeating "100644" really
isn't very interesting, and caring about mode changes is pretty rare).
Linus
---
#!/bin/sh
rm -rf merge-test
mkdir merge-test
cd merge-test/
git-init-db
echo "hello" > a
echo "hi there" > b
git add a b
git commit -m "Initial commit of 'a' and 'b'"
git branch other
echo "different hello" > a
git commit -m "Changed 'a'" a
git checkout other
echo "another different hello" > a
git commit -m "Changed 'a' differently" a
git checkout master
git merge "merge other" HEAD other >& /dev/null
echo "final hello" > a
rm -f b
echo "new file" > c
git-update-index --add --remove a b c
git commit -m "Evil merge"
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Linus Torvalds @ 2006-02-09 20:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602091216460.2458@g5.osdl.org>
On Thu, 9 Feb 2006, Linus Torvalds wrote:
>
> Here's a test-case, in case you care. Do "git-diff-tree --cc HEAD" in the
> merge-test directory.
Btw, that test-case is also designed to show the different M/A/D cases for
the merge result. The merge diff obviously doesn't do rename/copy
detection (I don't think it's necessarily even a well-defined op, or if
it is, it's damn complicated).
Linus
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-09 20:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602091216460.2458@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I found another nitpick: file removal doesn't seem to generate a good
> diff in "git-diff-tree --cc" (but it's correct in the new "raw" format
> diff).
>
> Here's a test-case, in case you care.
Actually, I've known about the removals and have excuse in one
of the commits why it does not show them.
It is an excuse (the internal data structure is not really
suited to show removal diff), but I think what the excuse gives
as the official reasoning behind it sort of make sense from
usability point of view as well.
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-09 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602091235210.2458@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 9 Feb 2006, Linus Torvalds wrote:
>>
>> Here's a test-case, in case you care. Do "git-diff-tree --cc HEAD" in the
>> merge-test directory.
>
> Btw, that test-case is also designed to show the different M/A/D cases for
> the merge result. The merge diff obviously doesn't do rename/copy
> detection (I don't think it's necessarily even a well-defined op, or if
> it is, it's damn complicated).
Although I've never seriously tried it, I think "diff-tree --cc"
with -M or -C should do a decent job. The initial phase to feed
combine-diff runs with the supplied rename/copy options if I am
not mistaken, and from the result it grabs one->{sha1,mode} (for
parent) and two->{sha1,mode} (obviously for merge result) to
feed combine-diff logic, while discarding one->path information.
So obviously it would show the final paths and would not talk
about which different path from each parent contributed to the
result, but otherwise it should not be broken too much. At
least that was the way I intended..
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Linus Torvalds @ 2006-02-09 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5hw9sk1.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Feb 2006, Junio C Hamano wrote:
>
> Actually, I've known about the removals and have excuse in one
> of the commits why it does not show them.
>
> It is an excuse (the internal data structure is not really
> suited to show removal diff), but I think what the excuse gives
> as the official reasoning behind it sort of make sense from
> usability point of view as well.
Fair enough. It looks a bit strange in gitk, but maybe that could be
rectified by just making the new/deleted file case say so explcitly
instead of having the "mode" line.
So instead of just "mode", how about saying "deleted file mode" or
"new file mode" the way that the regular diffs do (but then not showing
the contents for the deleted case).
Linus
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-09 20:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v8xsk9s3v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> So obviously it would show the final paths and would not talk
> about which different path from each parent contributed to the
> result, but otherwise it should not be broken too much. At
> least that was the way I intended..
Sorry, I am wrong again. That was the way how I planned to, but
I think I forgot to pass the diff-options from the caller to
diff_tree_combined_merge(), so it does not do renames/copies.
Shouldn't be too hard to change it though...
^ 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