* 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
* Re: Tracking and committing back to Subversion?
From: Brian Smith @ 2006-02-10 0:50 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <43E7DA7F.6060503@vilain.net>
On Monday 06 February 2006 15:23, Sam Vilain wrote:
> >>Has anyone done any work on bidirectional access to SVN repositories?
> >>ie, tracking and committing.
> >
>> [snip]
>
> Indeed, mirroring SVN repositories via SVN::Mirror (which is used by
> SVK) can take hours for large projects with thousands of commits.
>
Actually, I wasn't so much talking about the time required as the fact that
git-svnimport expects a very specific directory format, and KDE, since it was
migrated from CVS doesn't follow it, not to mention, I'm writing my tools
for the purpose of tracking single projects (i.e. Kopete which is part of KDE
project).
>> [snip]
>
> 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, 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. ;)
> Are you planning on publishing these scripts?
>
Sure, you can actually pick up the current development straight from
git://linuxfood.net/pub/git/kosek.git
Brian
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-02-10 0:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43EB290A.6060407@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> 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.
Yes, rebase would help somewhat (I said that didn't I?). But
the thing is, with the "pu" workflow of mine so far, I _did_
rewrite/replace commits on my topic branches, especially when
they are young and not in a good shape.
For example, the topic branch jc/nostat ("Assume unchanged" git)
has four commits since it forked from the mainline:
+ [jc/nostat] "Assume unchanged" git: --really-refresh fix.
+ [jc/nostat^] ls-files: debugging aid for CE_VALID changes.
+ [jc/nostat~2] "Assume unchanged" git: do not set CE_VALID with --refresh
+ [jc/nostat~3] "Assume unchanged" git
With the "pu" workflow, I would have merged the "do not set
CE_VALID" commit and "--really-refresh fix" commit into the
first "Assume unchanged" commit after I found out about these
two small mistakes. So one day "pu" would have contained what
is there right now as "jc/nostat~3", but the next day it would
have a commit, perhaps with slightly modified log message from
what is there as "jc/nostat~3" to contain fixes jc/nostat~2 and
jc/nostat have right now (the ls-files one is a debugging aid so
I would have left it separate even with the rewriting-history
workflow).
That kind of rewriting history is not being honest, but the end
result is that people do not have to see intermediate states and
earlier mistakes when things are fully cooked and ready to be
merged into the mainline. By promising not to rewind "next" and
topic branches that go to "next", I am closing the door for me
to do this kind of history rewrite freely. I can still rewrite
things I have not pushed out yet, though.
BTW, it is always a judgement call if it is a good thing to
squash commits into one like this. Being too honest hurts the
usability of the history. Especially if you have a trivial "Oh,
what I checked in does not even compile" kind of mistakes left
in the development trail, that would inconvenience bisection.
Being too sanitized OTOH tends to drop a single big ball of wax
into the history, and makes correcting things harder if it is
found later that only parts of that change are desired and the
other parts are not.
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-02-10 0:46 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060210004040.GB2866@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Note that I don't believe there is any need to combine the hunks, just
> stick them there in order and it *should* do the right thing.
Probably not. I suspect it would not like two pieces of diffs
touching the same path in a batch.
Feeding one at a time is OK, though.
^ permalink raw reply
* Re: What's in git.git
From: Ryan Anderson @ 2006-02-10 0:40 UTC (permalink / raw)
To: Luck, Tony; +Cc: Junio C Hamano, git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F05AA1FB3@scsmsx401.amr.corp.intel.com>
On Thu, Feb 09, 2006 at 03:49:16PM -0800, Luck, Tony wrote:
> Looks very close to what I want.
>
> > git checkout topic
> > git format-patch --stdout origin > topic-diff
>
> topic-diff contains each commit as a separate message
>
> > $VISUAL topic-diff
> > # Fix comments
>
> so this needs some skill & care to rearrange the pieces
> and end up with legal input to git-am
Doh, right, I was thinking "git apply" actually. (Apply the whole thing
as single diff - the comments from each commit in the middle should get
ignored.)
Note that I don't believe there is any need to combine the hunks, just
stick them there in order and it *should* do the right thing.
> Perhaps I'd like to have:
>
> git diff SHA-where-I-branched..HEAD
>
> but I don't see the way to compute the SHA-where-I-branched
git-merge-base topic master ?
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-02-10 0:35 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <7v8xsk5a6k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Luck, Tony" <tony.luck@intel.com> writes:
>
>> Looks very close to what I want.
>>
>>> git checkout topic
>>> git format-patch --stdout origin > topic-diff
>>
>> topic-diff contains each commit as a separate message
>>
>>> $VISUAL topic-diff
>>> # Fix comments
>>
>> so this needs some skill & care to rearrange the pieces
>> and end up with legal input to git-am
>>
>> Perhaps I'd like to have:
>>
>> git diff SHA-where-I-branched..HEAD
>>
>> but I don't see the way to compute the SHA-where-I-branched
>>
>> -Tony
>
> If what you want to end up with is a single commit, that is
> easy.
>
> If your topic branch is only "fork from master and never
> re-merge with master but just pile new commits on top of the
> tip, single strand of pearls" kind,
>
> git-merge-base master topic
>
> would find the 'x' commit, where you forked from:
>
> "master"
> ---x---o---o---o---o
> \
> o---o---o---o
> "topic"
>
> If you have "my topic will conflict with a change recently done
> in master so let's merge up from master to resolve conflict
> before going further" kind of merge commit on your topic branch,
> then you cannot have a single two-tree diff easily anyway, but
> in such a case, the following steps would work.
>
> "master"
> ---o---o---o---o---o
> \ \
> o---o---*---o
> "topic"
>
> (1) First merge "master" into "topic":
>
> $ git checkout topic
> $ git pull . master
>
> "master"
> ---o---o---o---o---o
> \ \ \
> o---o---*---o---*
> "topic"
>
> which would give you the rightmost '*' merge.
>
> (2) Extract diff from "master" to '*':
>
> $ git diff HEAD^2 HEAD >P.diff
>
> HEAD^1 is previous "topic" head and HEAD^2 is what you
> merged ("master").
>
> (3) Pick commits only on "topic" branch but not on "master"
>
> $ git rev-list --pretty --no-merges master..topic >P.log
>
> This will pick up the three 'o' commits on the lower
> development track and show their commit log message.
>
>
> (4) Reset the "topic" branch to "master", and do the squashed
> commit:
>
> $ git reset --hard master
> $ git apply --index P.diff
> $ git commit -F P.log -e
>
> This obviously would work equally well for single strand of
> pearls case. Maybe you can package the above up, and send in a
> patch to add "git-squash" command?
I am stupid. (4) can be done a lot more easily. Do not do step
(2) -- you do not need a diff at all. But do do step (3) to get
the logs. Then:
$ git reset --soft master
$ git commit -F P.log -e
What --soft reset does is to keep the index and the working tree
as is, but just change the current branch head to point at the
named commit. So, immediately after the above soft reset, your
commit ancestry graph looks like this:
"master"
---o---o---o---o---o
"topic"
and the last commit finally would give you:
"master"
---o---o---o---o---o
\
o
"topic"
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-02-10 0:28 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F05AA1FB3@scsmsx401.amr.corp.intel.com>
"Luck, Tony" <tony.luck@intel.com> writes:
> Looks very close to what I want.
>
>> git checkout topic
>> git format-patch --stdout origin > topic-diff
>
> topic-diff contains each commit as a separate message
>
>> $VISUAL topic-diff
>> # Fix comments
>
> so this needs some skill & care to rearrange the pieces
> and end up with legal input to git-am
>
> Perhaps I'd like to have:
>
> git diff SHA-where-I-branched..HEAD
>
> but I don't see the way to compute the SHA-where-I-branched
>
> -Tony
If what you want to end up with is a single commit, that is
easy.
If your topic branch is only "fork from master and never
re-merge with master but just pile new commits on top of the
tip, single strand of pearls" kind,
git-merge-base master topic
would find the 'x' commit, where you forked from:
"master"
---x---o---o---o---o
\
o---o---o---o
"topic"
If you have "my topic will conflict with a change recently done
in master so let's merge up from master to resolve conflict
before going further" kind of merge commit on your topic branch,
then you cannot have a single two-tree diff easily anyway, but
in such a case, the following steps would work.
"master"
---o---o---o---o---o
\ \
o---o---*---o
"topic"
(1) First merge "master" into "topic":
$ git checkout topic
$ git pull . master
"master"
---o---o---o---o---o
\ \ \
o---o---*---o---*
"topic"
which would give you the rightmost '*' merge.
(2) Extract diff from "master" to '*':
$ git diff HEAD^2 HEAD >P.diff
HEAD^1 is previous "topic" head and HEAD^2 is what you
merged ("master").
(3) Pick commits only on "topic" branch but not on "master"
$ git rev-list --pretty --no-merges master..topic >P.log
This will pick up the three 'o' commits on the lower
development track and show their commit log message.
(4) Reset the "topic" branch to "master", and do the squashed
commit:
$ git reset --hard master
$ git apply --index P.diff
$ git commit -F P.log -e
This obviously would work equally well for single strand of
pearls case. Maybe you can package the above up, and send in a
patch to add "git-squash" command?
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Junio C Hamano @ 2006-02-10 0:13 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87bqxgxfl7.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> So, what I'm trying to work towards is a situtation where those
> workflows are captured through obviously-correlated command
> subsets. This is what I was getting at in the PS. of my previous
> post. For example, the above could be, (ignoring the clash with
> existing core commands), something like:
>
> 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. But I am hesitant to declare these two
workflows as the _only_ ones officially supported by the tool at
this moment. The collective use pattern of git is still young
and leaving the door open would help us to evolve more useful
workflows around the core in the future. 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. By that time, hopefully many useless workflows (my
"constantly rewinding pu branch" pattern _could_ fall into that
category) would be withered away and it would be a good time to
streamline the tool around officially supported workflows.
My feeling is that it is a bit premature to do that right now; I
do not think we are there yet.
> Sure. In that light, try to conceive as my proposed "diff-files" and
> "diff-index" commands as two new highlevel commands. They would be
> useful in day-to-day operation, and most commonly without any need for
> command-line arguments. Those two operations exist today within the
> git-diff wrapper already as "diff HEAD" and "diff --cached HEAD" (or
> "diff --cached). But as described above, I think it would be better to
> put these operations on separate command names, and get them down to
> not requiring any command-line arguments in their common usage.
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. If the sample set of
barebone Porcelains do not fit your needs, you can mix and match
using lowlevel commands to quickly script your customized ones.
If that is useful in general, that would become one of the best
current practices.
> If you compare my above two chunks of example commands, there's nothing
> like a low-level vs. high-level distinction between them. It's more
> about separate command names being uses for different use cases and
> consistent naming used to group related commands within a use case.
I think that is where we differ. I think even for index-lover
"diff HEAD" is useful in certain cases (obviously index-ignorer
would not see much useful output from "diff --cached", though).
In fact, I fall into "index-lover" camp but I use both depending
on occasion. 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.
^ permalink raw reply
* Re: [PATCH] remove delta-against-self bit
From: Junio C Hamano @ 2006-02-09 23:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602091736500.5397@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> Said bit would in fact be more useful to allow for encoding the copying
> of chunks larger than 64KB providing more savings with large files.
> This will correspond to packs version 3.
>
> While the current code still produces packs version 2, it is made future
> proof so pack versions 2 and 3 are accepted. Any pack version 2 are
> compatible with version 3 since the redefined bit was never used before.
> When enough time has passed, code to use that bit to produce version 3
> packs could be added.
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?
^ permalink raw reply
* RE: What's in git.git
From: Luck, Tony @ 2006-02-09 23:49 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
Looks very close to what I want.
> git checkout topic
> git format-patch --stdout origin > topic-diff
topic-diff contains each commit as a separate message
> $VISUAL topic-diff
> # Fix comments
so this needs some skill & care to rearrange the pieces
and end up with legal input to git-am
Perhaps I'd like to have:
git diff SHA-where-I-branched..HEAD
but I don't see the way to compute the SHA-where-I-branched
-Tony
^ permalink raw reply
* [PATCH] combine-diff: move formatting logic to show_combined_diff()
From: Junio C Hamano @ 2006-02-09 23:49 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:
> 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.
This comes on top of the earlier "use diffcore_std()" patch.
-- >8 --
This way, diff-files can make use of it. Also implement the
full suite of what diff_flush_raw() supports just for
consistency. With this, 'diff-tree -c -r --name-status' would
show what is expected.
There is no way to get the historical output (useful for
debugging and low-level Plumbing work) anymore, so tentatively
it makes '-m' to mean "do not combine and show individual diffs
with parents".
diff-files matches diff-tree to produce raw output for -c. For
textual combined diff, use -p -c.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
combine-diff.c | 85 ++++++++++++++++++++++++++++++++++++++------------------
diff-files.c | 6 ++--
diff-tree.c | 2 +
diff.h | 3 +-
4 files changed, 64 insertions(+), 32 deletions(-)
0a798076b8d1a4a31bf2b24c564e2a99fd1c43a1
diff --git a/combine-diff.c b/combine-diff.c
index 6d78305..9aa099b 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -618,8 +618,8 @@ static void reuse_combine_diff(struct sl
sline->p_lno[i] = sline->p_lno[j];
}
-int show_combined_diff(struct combine_diff_path *elem, int num_parent,
- int dense, const char *header)
+static int show_patch_diff(struct combine_diff_path *elem, int num_parent,
+ int dense, const char *header)
{
unsigned long size, cnt, lno;
char *result, *cp, *ep;
@@ -791,32 +791,69 @@ static void show_raw_diff(struct combine
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)
+ if (p->parent[i].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 = " ";
+ if (opt->output_format == DIFF_FORMAT_RAW) {
+ 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);
+
+ /* Show sha1's */
+ for (i = 0; i < num_parent; i++)
+ printf(" %s", diff_unique_abbrev(p->parent[i].sha1,
+ opt->abbrev));
+ printf(" %s ", diff_unique_abbrev(p->sha1, opt->abbrev));
+ }
+
+ if (opt->output_format == DIFF_FORMAT_RAW ||
+ opt->output_format == DIFF_FORMAT_NAME_STATUS)
+ printf("%c%c", mod_type, inter_name_termination);
+
+ if (line_termination) {
+ if (quote_c_style(p->path, NULL, NULL, 0))
+ quote_c_style(p->path, NULL, stdout, 0);
+ else
+ printf("%s", p->path);
+ putchar(line_termination);
}
- printf("%s%s", prefix, diff_unique_abbrev(p->sha1, opt->abbrev));
+ else {
+ printf("%s%c", p->path, line_termination);
+ }
+}
- /* Modification type, terminations, filename */
- printf(" %c%c%s%c", mod_type, inter_name_termination, p->path, line_termination);
+int show_combined_diff(struct combine_diff_path *p,
+ int num_parent,
+ int dense,
+ const char *header,
+ struct diff_options *opt)
+{
+ if (!p->len)
+ return 0;
+ switch (opt->output_format) {
+ case DIFF_FORMAT_RAW:
+ case DIFF_FORMAT_NAME_STATUS:
+ case DIFF_FORMAT_NAME:
+ show_raw_diff(p, num_parent, header, opt);
+ return 1;
+
+ default:
+ case DIFF_FORMAT_PATCH:
+ return show_patch_diff(p, num_parent, dense, header);
+ }
}
const char *diff_tree_combined_merge(const unsigned char *sha1,
@@ -858,14 +895,8 @@ const char *diff_tree_combined_merge(con
}
if (num_paths) {
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))
+ if (show_combined_diff(p, num_parent, dense,
+ header, opt))
header = NULL;
}
}
diff --git a/diff-files.c b/diff-files.c
index d24d11c..7db5ce6 100644
--- a/diff-files.c
+++ b/diff-files.c
@@ -88,9 +88,8 @@ int main(int argc, const char **argv)
}
argv++; argc--;
}
- if (combine_merges) {
+ if (dense_combined_merges)
diff_options.output_format = DIFF_FORMAT_PATCH;
- }
/* Find the directory, and set up the pathspec */
pathspec = get_pathspec(prefix, argv + 1);
@@ -166,7 +165,8 @@ int main(int argc, const char **argv)
if (combine_merges && num_compare_stages == 2) {
show_combined_diff(&combine.p, 2,
dense_combined_merges,
- NULL);
+ NULL,
+ &diff_options);
free(combine.p.path);
continue;
}
diff --git a/diff-tree.c b/diff-tree.c
index df6fd97..b170b03 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -248,7 +248,7 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(arg, "-m")) {
- ignore_merges = 0;
+ combine_merges = ignore_merges = 0;
continue;
}
if (!strcmp(arg, "-c")) {
diff --git a/diff.h b/diff.h
index 9088519..946a406 100644
--- a/diff.h
+++ b/diff.h
@@ -75,7 +75,8 @@ struct combine_diff_path {
sizeof(struct combine_diff_parent) * (n) + (l) + 1)
extern int show_combined_diff(struct combine_diff_path *elem, int num_parent,
- int dense, const char *header);
+ int dense, const char *header,
+ struct diff_options *);
extern const char *diff_tree_combined_merge(const unsigned char *sha1, const char *, int, struct diff_options *opt);
--
1.1.6.gce16
^ permalink raw reply related
* Re: Two crazy proposals for changing git's diff commands
From: Carl Worth @ 2006-02-09 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfymtl43b.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 4779 bytes --]
On Wed, 08 Feb 2006 17:21:12 -0800, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
> > Can anyone else think of common use cases for these various
> > operations that I've missed?
>
> If there is none, then that means we have covered everything.
> But a more interesting question to ask is "are there useful
> comparisons that the existing diff lowlevel does not give me
> with a single command". And the answer is of course yes.
Yes, that's a more useful way to ask the question.
> For example, you cannot preview "git commit --include paths..."
> with a single low-level command. You would need to run
> "git-diff-index --cached HEAD" for paths that are _not_
> specified, and "git-diff-index HEAD" output for paths that you
> will give to "--include" when you make that commit.
Personally, I see that as an argument against adding the --include
semantics. It's a single command that is committing a mix of the index
and the current files, (which neither "commit" nor "commit -a"
do). Granted, Linus has said that he has relied on these existing
semantics, (but he also conceded willingness to retrain to
"update-index paths; commit" instead).
So there's some food for though there.
> Of course, learning various flags to give "git diff" is part of
> understanding the index, so if the user understands index, "git
> diff" without arguments will _not_ be the only diff command the
> user uses for a preview. And I suspect that depending on what
> development style you would use, the definition of "useful
> comparisons" would be different.
Yes, and I think it would be nice if the different workflows could be
captured by different subsets of commands, (rather than a mishmash of
different options to the same commands).
For example, I *think* we have consensus that two different, equally
reasonable, workflows might currently use the following sets of
commands (this is for basic work-preview-commit):
Index-lover:
update-index
diff --cached
commit
Index-ignorer:
diff HEAD
commit -a
So, what I'm trying to work towards is a situtation where those
workflows are captured through obviously-correlated command
subsets. This is what I was getting at in the PS. of my previous
post. For example, the above could be, (ignoring the clash with
existing core commands), something like:
Index-lover:
update-index
diff-index
commit-index
Index-ignorer:
diff-files
commit-files
[Note that due to the name clash problems, I'm not making a serious
proposal here---merely showing again the consistent naming I'm
interested in.]
The point of an exercise like that is that people could then settle on
appropriate workflows by reading a small subset of man pages that link
to each other, in their entirety. Compare that with the previous
command examples where the workflow is documented in little subsets of
man pages scattered about.
And please pardon me for my current fixation on the learnability of
git, but I am in the situation of "selling" git to my fellow
maintainers, (some of whom are saying "mercurial looks easier to
learn").
> No, the goal should be for normal workflows there should be *no*
> need to use lowlevel commands by end users day-to-day.
Sure. In that light, try to conceive as my proposed "diff-files" and
"diff-index" commands as two new highlevel commands. They would be
useful in day-to-day operation, and most commonly without any need for
command-line arguments. Those two operations exist today within the
git-diff wrapper already as "diff HEAD" and "diff --cached HEAD" (or
"diff --cached). But as described above, I think it would be better to
put these operations on separate command names, and get them down to
not requiring any command-line arguments in their common usage.
> I have not typed lowlevel commands from the command line for
> quite a long time, except when I am debugging, and except when I
> wanted to see "diff-tree --cc" output for a single commit, only
> because there was no suitable wrapper.
If you compare my above two chunks of example commands, there's nothing
like a low-level vs. high-level distinction between them. It's more
about separate command names being uses for different use cases and
consistent naming used to group related commands within a use case.
> The last reason is now
> gone thanks to "git-show" Linus added. So as far as *MY*
> workflow is concerned, that goal has already been achieved.
I confess that prior to reading the replies from you and Linus I had
never heard of git-show. I'll go look at that now, as well as consider
the suggestion to extend git-status to give me what I'm looking for.
Anyway, thanks for all the patience. I'm really enjoying the
conversation, and I hope I'm not being a bore.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-02-09 23:44 UTC (permalink / raw)
To: Tony Luck; +Cc: git
In-Reply-To: <12c511ca0602091514p35c3904bha8d5d406e5472969@mail.gmail.com>
Tony Luck <tony.luck@intel.com> writes:
> So is there an easy way in git to take the series of commits
> from a topic branch, make a new branch with all those commits
> as just one commit ... with an open editor on the concatenated
> commit comments (If there were just typo fixes the comment
> from the first commit would apply, but sometimes the follow-on
> commits would have substantive changes).
I do not have a script to do so but my guess is that would be a
20-30 line shell script. Use cherry to find which ones to pick,
run diff-tree on them to extract patches, run apply --index on
each of them in turn, and dump "git log master..topic" to your
editor and you are done. The editor would have the commit log
to be edited while working tree and the index would have a
ready-to-commit tree with all the changes applied.
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Junio C Hamano @ 2006-02-09 23:40 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87d5hwxhb5.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> I still think the three above operations are the most commonly needed,
> but I don't yet have good suggestions for names for them.
By "three" do you mean these three?
HEAD -> index
HEAD -> files
index -> files
The reason I am asking is because you already have them.
> I think I'll be back with some new proposals after considering your
> suggestion to expand git status.
I agree with Linus that "git status -v" with commit options to
give a commit preview is a very good change. That is one thing
I pointed out lacking from the current set of the tools in one
of the earlier message. I am not sure if you read what I wrote
in that message, but one approach I suggested for this thread to
take is to come up with a list of "useful comparisons" that the
current set of tools, especially "git diff" wrapper, does not
give you.
The three you listed above are not. They are useful, the
low-level natively support them, and "git diff" wrapper gives
easy shortcut for them. And one known "useful but not supported
one" will be tackled soon with "git status -v" change. Are
there other useful comparisons you wish you had that we do not
currently give you easily?
^ permalink raw reply
* Re: What's in git.git
From: Ryan Anderson @ 2006-02-09 23:30 UTC (permalink / raw)
To: Tony Luck; +Cc: Junio C Hamano, git
In-Reply-To: <12c511ca0602091514p35c3904bha8d5d406e5472969@mail.gmail.com>
On Thu, Feb 09, 2006 at 03:14:59PM -0800, Tony Luck wrote:
> On 2/8/06, Junio C Hamano <junkio@cox.net> wrote:
> > * If there are patches sent to improve a topic branch in it,
> > they will be applied to the topic branch, and then the topic
> > branch is merged into "next", without any funny rewinding or
> > rebasing of "next". This will make the "next" branch
> > cluttered with repeated merges from the same topic branch,
> > but that is OK. "next" will not be merged into "master",
> > ever.
> >
> > * Once a topic is fully cooked, the topic branch will be merged
> > into "master".
>
> This is pretty much the workflow in my test/release branches (mostly
> documented in Documentation/howto/using-topic-branches.txt).
>
> I've sometimes wondered about re-creating the topic branches in
> the case where there have been a series of follow-on commits
> before pulling them into the release branch. The goal would be
> to present history not as it was, but as it should have been if we
> didn't have all the dumb mistakes and typos.
>
> So is there an easy way in git to take the series of commits
> from a topic branch, make a new branch with all those commits
> as just one commit ... with an open editor on the concatenated
> commit comments (If there were just typo fixes the comment
> from the first commit would apply, but sometimes the follow-on
> commits would have substantive changes).
git checkout topic
git format-patch --stdout origin > topic-diff
$VISUAL topic-diff
# Fix comments
git checkout master
git checkout -b new-topic master
git-am topic-diff
.. done?
(I typically do something akin to this before sending patches to Junio,
by looking at the output of format-patch in a directory, editing,
combining a few changes if necessary, then re-committing, re-running
format-patch, and sending the output upstream.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: What's in git.git
From: Tony Luck @ 2006-02-09 23:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslqtf2p1.fsf@assigned-by-dhcp.cox.net>
On 2/8/06, Junio C Hamano <junkio@cox.net> wrote:
> * If there are patches sent to improve a topic branch in it,
> they will be applied to the topic branch, and then the topic
> branch is merged into "next", without any funny rewinding or
> rebasing of "next". This will make the "next" branch
> cluttered with repeated merges from the same topic branch,
> but that is OK. "next" will not be merged into "master",
> ever.
>
> * Once a topic is fully cooked, the topic branch will be merged
> into "master".
This is pretty much the workflow in my test/release branches (mostly
documented in Documentation/howto/using-topic-branches.txt).
I've sometimes wondered about re-creating the topic branches in
the case where there have been a series of follow-on commits
before pulling them into the release branch. The goal would be
to present history not as it was, but as it should have been if we
didn't have all the dumb mistakes and typos.
So is there an easy way in git to take the series of commits
from a topic branch, make a new branch with all those commits
as just one commit ... with an open editor on the concatenated
commit comments (If there were just typo fixes the comment
from the first commit would apply, but sometimes the follow-on
commits would have substantive changes).
-Tony
^ permalink raw reply
* Re: Two crazy proposals for changing git's diff commands
From: Carl Worth @ 2006-02-09 23:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602081719250.2458@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
On Wed, 8 Feb 2006 17:21:49 -0800 (PST), Linus Torvalds wrote:
> >
> > The largest reason for why "git diff" defaults to diffing against the
> > index (and not head) is _literally_ that it's faster.
That's certainly surprising history to learn.
> Btw, it was kind of luck (but it's definitely true) that the current "git
> diff" semantics happen to also be what you do want during merges when you
> try to resolve a conflict (while "git diff HEAD" is much less useful).
>
> So making "git diff" default to diffing against HEAD is actually the wrong
> thing to do during merging, where the current behaviour is exactly what
> you'd want.
I discovered this during the analysis and guess (incorrectly) that it
was the motivation for the behavior of "git diff". Initially I think I
would have made a proposal that had "git diff" creating a diff from
HEAD except that I discovered two different targets that would be
useful when diffing from HEAD:
HEAD -> index
and: HEAD -> files
so I chose "index" and "files" as the naming distinction there. In
light of those, I couldn't think of any good naming for the remaining:
index -> files
operation, so it seemed just as well to leave it with a bare "diff" as
before.
But, as you've pointed out, my trying to create new high-level
diff-index and diff-files operations fails in that it clashes with the
existing low-level uses of those names, (which scripts may already be
depending on).
I totally neglected to consider the pain of migrating scripts.
I still think the three above operations are the most commonly needed,
but I don't yet have good suggestions for names for them.
I think I'll be back with some new proposals after considering your
suggestion to expand git status.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] remove delta-against-self bit
From: Nicolas Pitre @ 2006-02-09 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
After experimenting with code to add the ability to encode a delta
against part of the deltified file, it turns out that resulting packs
are _bigger_ than when this ability is not used. The raw delta output
might be smaller, but it doesn't compress as well using gzip with a
negative net saving on average.
Said bit would in fact be more useful to allow for encoding the copying
of chunks larger than 64KB providing more savings with large files.
This will correspond to packs version 3.
While the current code still produces packs version 2, it is made future
proof so pack versions 2 and 3 are accepted. Any pack version 2 are
compatible with version 3 since the redefined bit was never used before.
When enough time has passed, code to use that bit to produce version 3
packs could be added.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/patch-delta.c b/patch-delta.c
index 98c27be..c0e1311 100644
--- a/patch-delta.c
+++ b/patch-delta.c
@@ -44,16 +44,15 @@ void *patch_delta(void *src_buf, unsigne
cmd = *data++;
if (cmd & 0x80) {
unsigned long cp_off = 0, cp_size = 0;
- const unsigned char *buf;
if (cmd & 0x01) cp_off = *data++;
if (cmd & 0x02) cp_off |= (*data++ << 8);
if (cmd & 0x04) cp_off |= (*data++ << 16);
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;
- buf = (cmd & 0x40) ? dst_buf : src_buf;
- memcpy(out, buf + cp_off, cp_size);
+ memcpy(out, src_buf + cp_off, cp_size);
out += cp_size;
} else {
memcpy(out, data, cmd);
diff --git a/pack.h b/pack.h
index 657deaa..9dafa2b 100644
--- a/pack.h
+++ b/pack.h
@@ -21,6 +21,7 @@ enum object_type {
*/
#define PACK_SIGNATURE 0x5041434b /* "PACK" */
#define PACK_VERSION 2
+#define pack_version_ok(v) ((v) == htonl(2) || (v) == htonl(3))
struct pack_header {
unsigned int hdr_signature;
unsigned int hdr_version;
diff --git a/index-pack.c b/index-pack.c
index 541d7bc..babe34b 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -68,9 +68,9 @@ static void parse_pack_header(void)
hdr = (void *)pack_base;
if (hdr->hdr_signature != htonl(PACK_SIGNATURE))
die("packfile '%s' signature mismatch", pack_name);
- if (hdr->hdr_version != htonl(PACK_VERSION))
- die("packfile '%s' version %d different from ours %d",
- pack_name, ntohl(hdr->hdr_version), PACK_VERSION);
+ if (!pack_version_ok(hdr->hdr_version))
+ die("packfile '%s' version %d unsupported",
+ pack_name, ntohl(hdr->hdr_version));
nr_objects = ntohl(hdr->hdr_entries);
diff --git a/pack-check.c b/pack-check.c
index 511f294..67a7ecd 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -16,9 +16,9 @@ static int verify_packfile(struct packed
hdr = p->pack_base;
if (hdr->hdr_signature != htonl(PACK_SIGNATURE))
return error("Packfile %s signature mismatch", p->pack_name);
- if (hdr->hdr_version != htonl(PACK_VERSION))
- return error("Packfile version %d different from ours %d",
- ntohl(hdr->hdr_version), PACK_VERSION);
+ if (!pack_version_ok(hdr->hdr_version))
+ return error("Packfile version %d unsupported",
+ ntohl(hdr->hdr_version));
nr_objects = ntohl(hdr->hdr_entries);
if (num_packed_objects(p) != nr_objects)
return error("Packfile claims to have %d objects, "
diff --git a/pack-objects.c b/pack-objects.c
diff --git a/unpack-objects.c b/unpack-objects.c
index 4b5b5cb..815a1b3 100644
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -246,13 +246,12 @@ static void unpack_all(void)
{
int i;
struct pack_header *hdr = fill(sizeof(struct pack_header));
- unsigned version = ntohl(hdr->hdr_version);
unsigned nr_objects = ntohl(hdr->hdr_entries);
if (ntohl(hdr->hdr_signature) != PACK_SIGNATURE)
die("bad pack file");
- if (version != PACK_VERSION)
- die("unable to handle pack file version %d", version);
+ if (!pack_version_ok(hdr->hdr_version))
+ die("unknown pack file version %d", ntohl(hdr->hdr_version));
fprintf(stderr, "Unpacking %d objects\n", nr_objects);
use(sizeof(struct pack_header));
^ permalink raw reply related
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-09 22:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vk6c48a69.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> On top of your patch, it was quite easy ;-)
>>
>> After the "Evil merge" in your test script, I added these:
>>
>>...
>>
>> git diff-tree -M --cc HEAD
>
> Sorry for the noise. The test was broken.
Second try. Sorry again for the previous noise.
This time I made sure I am getting double-colon output;
here is what I added after your test script:
for i in a b c d e f g h i j k l m n; do echo $i; done >d
git-update-index --add d
git commit -m 'Add d'
git checkout other
git merge fast HEAD master
echo o >>d
git-update-index d
git commit -m 'Edit d'
git checkout master
echo 'Another' >>a
git-update-index a
git commit -m 'Modify a'
git merge --no-commit 'Merge' HEAD other
echo Extra >>a
mv d e
echo extra >>e
git update-index --add --remove a d e
git commit -m 'Evil again'
git diff-tree -M -c HEAD
But you are right. Rename detection with combined diff has a
funny semantics:
diff-tree 9df5f2d... (from parents)
Merge: 1da47fa... 09eee61...
Author: Junio C Hamano <junkio@cox.net>
Date: Thu Feb 9 14:11:13 2006 -0800
Evil again
::100644 100644 100644 8c3beaf... aad9366... c54c990... M a
::100644 100644 100644 4f7cbe7... f8c295c... 19d5d80... M e
This is showing that what was "d" was somehow magically called
"e" in the merge result with its own changes. --cc output is
more interesting but the point is there is no sign of "d" in its
output, which does not feel right.
If we really care, we could show a status letter for each parent
(both are renames in this case but it is plausible one parent is
rename-edit and another is modify) and the original path in each
parent.
Does it matter? I presume that a Porcelain that cares would
rather use the traditional "diff-tree -m -r" to look at diff
with each parent. I dunno.
---
diff --git a/combine-diff.c b/combine-diff.c
index 15f369e..6d78305 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -829,7 +829,7 @@ const char *diff_tree_combined_merge(con
struct combine_diff_path *p, *paths = NULL;
int num_parent, i, num_paths;
- diff_setup(&diffopts);
+ diffopts = *opt;
diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
diffopts.recursive = 1;
@@ -846,6 +846,7 @@ const char *diff_tree_combined_merge(con
struct commit *parent = parents->item;
diff_tree_sha1(parent->object.sha1, commit->object.sha1, "",
&diffopts);
+ diffcore_std(&diffopts);
paths = intersect_paths(paths, i, num_parent);
diff_flush(&diffopts);
}
^ permalink raw reply related
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-09 22:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7voe1g8air.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> On top of your patch, it was quite easy ;-)
>
> After the "Evil merge" in your test script, I added these:
>
>...
>
> git diff-tree -M --cc HEAD
Sorry for the noise. The test was broken.
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-09 21:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v4q389rwi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> 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...
On top of your patch, it was quite easy ;-)
After the "Evil merge" in your test script, I added these:
for i in a b c d e f g h i j k l m n; do echo $i; done >d
git-update-index --add d
git commit -m 'Add d'
git checkout other
git merge fast HEAD master
mv d e
echo o >>e
git-update-index --add --remove d e
git commit -m 'Move-edit d to e'
git checkout master
git merge -s recursive 'Merge' HEAD other
git diff-tree -M --cc HEAD
diff --git a/combine-diff.c b/combine-diff.c
index 15f369e..2a0ec10 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -829,7 +829,7 @@ const char *diff_tree_combined_merge(con
struct combine_diff_path *p, *paths = NULL;
int num_parent, i, num_paths;
- diff_setup(&diffopts);
+ diffopts = *opt;
diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
diffopts.recursive = 1;
^ permalink raw reply related
* Re: Fatal error from git bisect
From: Junio C Hamano @ 2006-02-09 21:32 UTC (permalink / raw)
To: Mark E Mason; +Cc: git, Linus Torvalds
In-Reply-To: <7E000E7F06B05C49BDBB769ADAF44D0773A4BC@NT-SJCA-0750.brcm.ad.broadcom.com>
"Mark E Mason" <mark.e.mason@broadcom.com> writes:
> That did the trick. Thanks very much for the pointer, it's much
> appreciated.
Thanks, both of you. This got me worried, especially when I am
at work and cannot pull the whole mips tree to take a look at it
myself.
^ permalink raw reply
* RE: Fatal error from git bisect
From: Mark E Mason @ 2006-02-09 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Hello,
> From: Linus Torvalds [mailto:torvalds@osdl.org]
[snip]
> 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..
That did the trick. Thanks very much for the pointer, it's much
appreciated.
Thanks,
Mark
^ permalink raw reply
* Re: gitweb using "--cc"?
From: Junio C Hamano @ 2006-02-09 21:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602091246010.2458@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> 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).
Sounds sensible. Will do this evening after work.
^ 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