* Re: [COGITO PATCH] Small, simple and obvious cleanups (are they wanted at this stage?)
From: Petr Baudis @ 2005-06-05 20:25 UTC (permalink / raw)
To: C. Cooke; +Cc: git
In-Reply-To: <429E0B08.5040603@gkhs.net>
Dear diary, on Wed, Jun 01, 2005 at 09:22:48PM CEST, I got a letter
where "C. Cooke" <ccooke@gkhs.net> told me that...
> This is a simple example - giving a nice error if you're in the wrong
> directory.
>
> Is this sort of patch wanted? If so, I'm sure I can spare the time to
> look into some polishing.
Of course they are wanted. Thanks, applied.
> ------------------------------
> Add some sanity checking - does $_git exist, and is it writable.
>
> ---
> commit 06afdeefff9fe02cd2a67f223e687646cacf736f
> tree cebc55541b89b5370335fc172814feb48456dc85
> parent 20e473c9afd8b5d2d549b0e7881473600beb9c37
> author C. Cooke <ccooke@slab.earth.gkhs.net> Wed, 01 Jun 2005 20:03:46 +0100
> committer C. Cooke <ccooke@slab.earth.gkhs.net> Wed, 01 Jun 2005
> 20:03:46 +0100
>
> cg-Xnormid | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/cg-Xnormid b/cg-Xnormid
> --- a/cg-Xnormid
> +++ b/cg-Xnormid
> @@ -16,6 +16,15 @@
>
> id="$1"
>
> +# A little sanity checking.
> +if [ ! -d "$_git" ]; then
> + echo "There is no Git repository here ($_git not found)" >&2
> + exit 1
> +elif [ ! -r "$_git" ] || [ ! -x "$_git" ]; then
> + echo "You do not have permission to access this git repository" >&2
> + exit 1
> +fi
> +
> if [ ! "$id" ] || [ "$id" = "this" ] || [ "$id" = "HEAD" ]; then
> read id < "$_git/HEAD"
I removed the -r check. What is it good for?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [COGITO PATCH] Small, simple and obvious cleanups (are they wanted at this stage?)
From: Petr Baudis @ 2005-06-05 20:34 UTC (permalink / raw)
To: C. Cooke; +Cc: git
In-Reply-To: <20050605202527.GO17462@pasky.ji.cz>
Dear diary, on Sun, Jun 05, 2005 at 10:25:27PM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
> Dear diary, on Wed, Jun 01, 2005 at 09:22:48PM CEST, I got a letter
> where "C. Cooke" <ccooke@gkhs.net> told me that...
> > This is a simple example - giving a nice error if you're in the wrong
> > directory.
> >
> > Is this sort of patch wanted? If so, I'm sure I can spare the time to
> > look into some polishing.
>
> Of course they are wanted. Thanks, applied.
Ok, another thing I forgot to mention - I moved it to cg-Xlib so that
it's checked everytime you run a command, unless the command says it
does need a repository in order to run successfully (that's the case for
cg-clone, cg-init and cg-help).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] diff.c: locate_size_cache() fix.
From: Petr Baudis @ 2005-06-05 20:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <7vekbik6c0.fsf@assigned-by-dhcp.cox.net>
> This fixes two bugs.
>
> - declaration of auto variable "cmp" was preceeded by a
> statement, causing compilation error on real C compilers;
> noticed and patch given by Yoichi Yuasa.
>
> - the function's calling convention was overloading its size
> parameter to mean "largest possible value means do not add
> entry", which was a bad taste. Brought up during a
> discussion with Peter Baudis.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> This fixes a bug that was preventing non-default parameter to -B
> option to be passed correctly; you could not give more than 50%
> break score.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> This fixes three bugs in the -B heuristics.
>
> - Although it was advertised that the initial break criteria
> used was the same as what diffcore-rename uses, it was using
> something different. Instead of using smaller of src and dst
> size to compare with "edit" size, (insertion and deletion),
> it was using larger of src and dst, unlike the rename/copy
> detection logic. This caused the parameter to -B to mean
> something different from the one to -M and -C. To compensate
> for this change, the default break score is also changed to
> match that of the default for rename/copy.
>
> - The code would have crashed with division by zero when trying
> to break an originally empty file.
>
> - Contrary to what the comment said, the algorithm was breaking
> small files, only to later merge them together.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Hello,
what's up with those three fixes? Were they pointed out to be wrong
and thrown away in another thread, are they on hold or just dropped?
Should I just apply them to git-pb?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] One Git To Rule Them All - Prep 1
From: Petr Baudis @ 2005-06-05 20:47 UTC (permalink / raw)
To: torvalds; +Cc: Jason McMullan, git
In-Reply-To: <20050601055949.GA15813@port.evillabs.net>
Dear diary, on Wed, Jun 01, 2005 at 07:59:49AM CEST, I got a letter
where Jason McMullan <jason.mcmullan@timesys.com> told me that...
> one-git prep patch 1/2
>
> Add some missing documentation for git-* commands
>
> Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
>
> diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/git-apply.txt
> diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/git-get-tar-commit-id.txt
> diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/git-stripspace.txt
Linus? Even if we don't go for the One Git stuff, this would be
definitively nice to have.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-update with local uncommitted changes
From: Petr Baudis @ 2005-06-05 20:58 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: GIT Mailing List
In-Reply-To: <1117747614.3656.2.camel@pegasus>
Dear diary, on Thu, Jun 02, 2005 at 11:26:54PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,
>
> > > let me be more specific. It only works in the fast forward case. If we
> > > actually must merge the trees, because I have local committed changes
> > > and not committed changes, I see this:
> > >
> > > link 74966c42ddd874192c318acfc5f013e56c50606a
> > > link b27ddcd47e293557e0605b98b2a1e8429035cdc5
> > > link 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80
> > > Tree change: f345b0a066572206aac4a4f9a57d746e213b6bff:74966c42ddd874192c318acfc5f013e56c50606a
> > > :100644 100644 f5deac7be59e7eeab8657fd9ae706fd6a57daed2 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80 M README
> > >
> > > Applying changes...
> > > usage.c: needs update
> > > cg-merge: merge blocked: local changes
> > >
> > > I changed the README in test1 repository and committed it. Then I
> > > changed Makefile in test2 repository and committed it. After that I
> > > modified usage.c and left it uncommitted. Then I pulled in the README
> > > change from test1 repository.
> >
> > yes, and that is all right. If you are actually doing the merge with
> > commit, you need to have the tree clean before, since any changes you
> > make to the tree are counted as conflict fixes, and you don't want your
> > older changes to mix into that.
>
> but not if the merge does not conflict with the local changes. This is
> what Bitkeeper is doing. It lets you pull new stuff as long as it does
> not conflict with your local uncommitted changes. Actually I liked that
> feature a lot, because I was able the follow the latest Linux mainline
> tree and work on my stuff.
Well, I guess we could allow this to happen if there are no conflicts
whatsoever, but as soon as _any_ conflicts appear in the tree, we would
have to bail out screaming panic, asking you to commit your stuff.
Actually, if you've already committed something locally, why don't you
commit everything locally and keep some uncommitted changes on the top?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: cg-init bug -- identified
From: Junio C Hamano @ 2005-06-05 21:11 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20050605182912.GC6890@tumblerings.org>
>>>>> "ZB" == Zack Brown <zbrown@tumblerings.org> writes:
ZB> It turned out one of my files had a "'" in the name, i.e.:
ZB> $ ls
ZB> Zack's_file
ZB> $
ZB> I removed it, and all of a sudden cg-init worked perfectly.
ZB> Is that a Cogito bug? I would expect git to handle any
ZB> filename the filesystem itself can handle.
I'd be very surprised if it were a bug in the core GIT. On the
other hand, Cogito, being a bunch of shell scripts, has plenty
of pitfalls it can fall in, especially in quoting areas unless
it is written reasonably carefully.
^ permalink raw reply
* Re: [PATCH-CAREFUL/RENAME] rename git-rpush and git-rpull to git-ssh-push and git-ssh-pull
From: Linus Torvalds @ 2005-06-05 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vfyvxb89m.fsf_-_@assigned-by-dhcp.cox.net>
On Sat, 4 Jun 2005, Junio C Hamano wrote:
>
> *** Linus, please be careful with this patch. This uses
> *** extended git "rename" diff format, and I doubt that
> *** traditional patch -p1 would do the right thing.
Indeed.
However, I've now made "git-apply" fully functional, and as far as I can
tell, it would happily eat this patch. However, it so happens that your
patch conflicts with the other patches sent yesterday, so it won't.
Or maybe I screwed up. I applied your previous four patches with the new
magic git-apply thing, and it all _seems_ to work fine, but it might make
sense if you double-checked it, and then we'll try this again and use it
as the test-case for the new git-apply program.
Btw, while talking about "sensible", I really think somebody should look
my "apply.c" file over. It seems simple enough, and it does seem to work,
but considering that I just totally replaced "patch" in my applicator
script with this new thing, if it gets something wrong...
Linus
^ permalink raw reply
* [PATCH] Documentation: describe diff tweaking.
From: Junio C Hamano @ 2005-06-05 21:30 UTC (permalink / raw)
To: torvalds; +Cc: git
This adds documentation for the diffcore mechanism and explains
how numeric parameters to -B/-C/-M options affect the output,
which was left "black magic" so far.
The documentation is not connected to any of the other asciidoc
nodes yet. Awaiting for suggestions, fixes and help from other
people.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/diffcore.txt | 241 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 241 insertions(+), 0 deletions(-)
diff --git a/Documentation/diffcore.txt b/Documentation/diffcore.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/diffcore.txt
@@ -0,0 +1,241 @@
+Tweaking diff output
+====================
+June 2005
+
+
+Introduction
+------------
+
+The diff commands git-diff-cache, git-diff-files, and
+git-diff-tree can be told to manipulate differences they find
+in unconventional ways before showing diff(1) output. The
+manipulation is collectively called "diffcore transformation".
+This short note describes what they are and how to use them to
+produce diff outputs that are easier to understand than the
+conventional kind.
+
+
+The chain of operation
+----------------------
+
+The git-diff-* family works by first comparing two sets of
+files:
+
+ - git-diff-cache compares contents of a "tree" object and the
+ working directory (when --cached flag is not used) or a
+ "tree" object and the index file (when --cached flag is
+ used);
+
+ - git-diff-files compares contents of the index file and the
+ working directory;
+
+ - git-diff-tree compares contents of two "tree" objects.
+
+In all of these cases, the commands themselves compare
+corresponding paths in the two sets of files. The result of
+comparison is passed from these commands to what is internally
+called "diffcore", in a format similar to what is output when
+the -p option is not used. E.g.
+
+ in-place edit :100644 100644 bcd1234... 0123456... M file0
+ create :000000 100644 0000000... 1234567... N file4
+ delete :100644 000000 1234567... 0000000... D file5
+ unmerged :000000 000000 0000000... 0000000... U file6
+
+The diffcore mechanism is fed a list of such comparison results
+(each of which is called "filepair", although at this point each
+of them talks about a single file), and transforms such a list
+into another list. There are currently 7 such transformations:
+
+ - diffcore-pathspec
+ - diffcore-break
+ - diffcore-rename
+ - diffcore-merge-broken
+ - diffcore-pickaxe
+ - diffcore-order
+
+These are applied in sequence. The set of filepairs git-diff-*
+commands find are used as the input to diffcore-pathspec, and
+the output from diffcore-pathspec is used as the input to the
+next transformation. The final result is then passed to the
+output routine and generates either diff-raw format (see Output
+format sections of the manual for git-diff-* commands) or
+diff-patch format.
+
+
+diffcore-pathspec
+-----------------
+
+The first transformation in the chain is diffcore-pathspec, and
+is controlled by giving the pathname parameters to the
+git-diff-* commands on the command line. The pathspec is used
+to limit the world diff operates in. It removes the filepairs
+outside the specified set of pathnames.
+
+Implementation note. For performance reasons, git-diff-tree
+uses the pathname parameters on the command line to cull set of
+filepairs it feeds the diffcore mechanism itself, and does not
+use diffcore-pathspec, but the end result is the same.
+
+
+diffcore-break
+--------------
+
+The second transformation in the chain is diffcore-break, and is
+controlled by the -B option to the git-diff-* commands. This is
+used to detect a filepair that represents "complete rewrite" and
+break such filepair into two filepairs that represent delete and
+create. E.g. If the input contained this filepair:
+
+ :100644 100644 bcd1234... 0123456... M file0
+
+and if it detects that the file "file0" is completely rewritten,
+it changes it to:
+
+ :100644 000000 bcd1234... 0000000... D file0
+ :000000 100644 0000000... 0123456... N file0
+
+For the purpose of breaking a filepair, diffcore-break examines
+the extent of changes between the contents of the files before
+and after modification (i.e. the contents that have "bcd1234..."
+and "0123456..." as their SHA1 content ID, in the above
+example). The amount of deletion of original contents and
+insertion of new material are added together, and if it exceeds
+the "break score", the filepair is broken into two. The break
+score defaults to 50% of the size of the smaller of the original
+and the result (i.e. if the edit shrinks the file, the size of
+the result is used; if the edit lengthens the file, the size of
+the original is used), and can be customized by giving a number
+after "-B" option (e.g. "-B75" to tell it to use 75%).
+
+
+diffcore-rename
+---------------
+
+This transformation is used to detect renames and copies, and is
+controlled by the -M option (to detect renames) and the -C option
+(to detect copies as well) to the git-diff-* commands. If the
+input contained these filepairs:
+
+ :100644 000000 0123456... 0000000... D fileX
+ :000000 100644 0000000... 0123456... N file0
+
+and the contents of the deleted file fileX is similar enough to
+the contents of the created file file0, then rename detection
+merges these filepairs and creates:
+
+ :100644 100644 0123456... 0123456... R100 fileX file0
+
+When the "-C" option is used, the original contents of modified
+files and contents of unchanged files are considered as
+candidates of the source files in rename/copy operation, in
+addition to the deleted files. If the input were like these
+filepairs, that talk about a modified file fileY and a newly
+created file file0:
+
+ :100644 100644 0123456... 1234567... M fileY
+ :000000 100644 0000000... 0123456... N file0
+
+the original contents of fileY and the resulting contents of
+file0 are compared, and if they are similar enough, they are
+changed to:
+
+ :100644 100644 0123456... 1234567... M fileY
+ :100644 100644 0123456... 0123456... C100 fileY file0
+
+In both rename and copy detection, the same "extent of changes"
+algorithm used in diffcore-break is used to determine if two
+files are "similar enough", and can be customized to use
+similarity score different from the default 50% by giving a
+number after "-M" or "-C" option (e.g. "-M8" to tell it to use
+8/10 = 80%).
+
+Note. When the "-C" option is used, git-diff-cache and
+git-diff-file commands feed not just modified filepairs but
+unmodified ones to diffcore mechanism as well. This lets the
+copy detector consider unmodified files as copy source
+candidates at the expense of making it slower. Currently
+git-diff-tree does not feed unmodified filepairs even when the
+"-C" option is used, so it can detect copies only if the file
+that was copied happened to have been modified in the same
+changeset.
+
+
+diffcore-merge-broken
+---------------------
+
+This transformation is used to merge filepairs broken by
+diffcore-break, and were not transformed into rename/copy by
+diffcore-rename, back into a single modification. This always
+runs when diffcore-break is used.
+
+For the purpose of merging broken filepairs back, it uses a
+different "extent of changes" computation from the ones used by
+diffcore-break and diffcore-rename. It counts only the deletion
+from the original, and does not count insertion. If you removed
+only 10 lines from a 100-line document, even if you added 910
+new lines to make a new 1000-line document, you did not do a
+complete rewrite. diffcore-break breaks such a case in order to
+help diffcore-rename to consider such filepairs as candidate of
+rename/copy detection, but if filepairs broken that way were not
+matched with other filepairs to create rename/copy, then this
+transformation merges them back into the original
+"modification".
+
+The "extent of changes" parameter can be tweaked from the
+default 80% (that is, unless more than 80% of the original
+material is deleted, the broken pairs are merged back into a
+single modification) by giving a second number to -B option,
+like these:
+
+ -B50/60 (give 50% "break score" to diffcore-break, use
+ 60% for diffcore-merge-broken).
+ -B/60 (the same as above, since diffcore-break defautls to
+ 50%).
+
+
+diffcore-pickaxe
+----------------
+
+This transformation is used to find filepairs that represent
+changes that touch a specified string, and is controlled by the
+-S option and the --pickaxe-all option to the git-diff-*
+commands.
+
+When diffcore-pickaxe is in use, it checks if there are
+filepairs whose "original" side has the specified string and
+whose "result" side does not. Such a filepair represents "the
+string appeared in this changeset". It also checks for the
+opposite case that loses the specified string.
+
+When --pickaxe-all is not in effect, diffcore-pickaxe leaves
+only such filepairs that touches the specified string in its
+output. When --pickaxe-all is used, diffcore-pickaxe leaves all
+filepairs intact if there is such a filepair, or makes the
+output empty otherwise. The latter behaviour is designed to
+make reviewing of the changes in the context of the whole
+changeset easier.
+
+
+diffcore-order
+--------------
+
+This is used to reorder the filepairs according to the user's
+(or project's) taste, and is controlled by the -O option to the
+git-diff-* commands.
+
+This takes a text file each of whose line is a shell glob
+pattern. Filepairs that match a glob pattern on an earlier line
+in the file are output before ones that match a later line, and
+filepairs that do not match any glob pattern are output last.
+
+As an example, typical orderfile for the core GIT probably
+should look like this:
+
+ README
+ Makefile
+ Documentation
+ *.h
+ *.c
+ t
+
------------
^ permalink raw reply
* [PATCH] Documentation: describe git extended diff headers.
From: Junio C Hamano @ 2005-06-05 21:39 UTC (permalink / raw)
To: torvalds; +Cc: git
The documentation failed to describe "diff --git" extended diff
headers, so add some.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/diff-format.txt | 36 +++++++++++++++++++++++++++++++++++-
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -52,7 +52,7 @@ Generating patches with -p
--------------------------
When "git-diff-cache", "git-diff-tree", or "git-diff-files" are run
-with a '-p' option, they do not produce the output described above
+with a '-p' option, they do not produce the output described above;
instead they produce a patch file.
The patch generation can be customized at two levels. This
@@ -98,3 +98,37 @@ temporary file --- it is removed when 'G
For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
parameter, <path>.
+
+
+Git specific extention to diff format
+-------------------------------------
+
+What -p option produces is slightly different from the
+traditional diff format.
+
+ (1) It is preceeded with a "git diff" header, that looks like
+ this:
+
+ diff --git a/file1 b/file2
+
+ The a/ and b/ filenames are the same unless rename/copy is
+ involved. Especially, even for a creation or a deletion,
+ /dev/null is _not_ used in place of a/ or b/ filename.
+
+ When rename/copy is involved, file1 and file2 shows the
+ name of the source file of the rename/copy and the name of
+ the file that rename/copy produces, respectively.
+
+ (2) It is followed by extended header lines that are one or
+ more of:
+
+ old mode <mode>
+ new mode <mode>
+ deleted file mode <mode>
+ new file mode <mode>
+ copy from <path>
+ copy to <path>
+ rename from <path>
+ rename to <path>
+ similarity index <number>
+ dissimilarity index <number>
------------
^ permalink raw reply
* Re: [PATCH] Documentation: describe git extended diff headers.
From: Linus Torvalds @ 2005-06-05 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voeak1o0q.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Jun 2005, Junio C Hamano wrote:
>
> The documentation failed to describe "diff --git" extended diff
> headers, so add some.
You document the "rename" header as being "rename from/to", which is
sensible, but doesn't match reality. diff.c has "rename old/new". I found
that out the hard way when doing git-apply ;)
I'd almost prefer fixing diff.c (and now apply.c). Comments?
Linus
^ permalink raw reply
* [PATCH] Fix diff.c to match rename extended header to the document.
From: Junio C Hamano @ 2005-06-05 22:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506051509490.1876@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Sun, 5 Jun 2005, Junio C Hamano wrote:
>>
>> The documentation failed to describe "diff --git" extended diff
>> headers, so add some.
LT> You document the "rename" header as being "rename from/to", which is
LT> sensible, but doesn't match reality. diff.c has "rename old/new". I found
LT> that out the hard way when doing git-apply ;)
LT> I'd almost prefer fixing diff.c (and now apply.c). Comments?
Yes, sir ;-).
------------
This matches the git extended header to what is documented.
There is no need to touch git-external-diff-script since it gets
the string generated here and simply spits it out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff
# - linus: git-apply: fix rename header parsing
# + (working tree)
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -786,8 +786,8 @@ static void diff_flush_patch(struct diff
case 'R':
sprintf(msg_,
"similarity index %d%%\n"
- "rename old %s\n"
- "rename new %s",
+ "rename from %s\n"
+ "rename to %s",
(int)(0.5 + p->score * 100.0/MAX_SCORE),
p->one->path, p->two->path);
msg = msg_;
Compilation finished at Sun Jun 5 15:23:44
^ permalink raw reply
* [PATCH] Fix apply.c to match rename extended header to the document.
From: Junio C Hamano @ 2005-06-05 22:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506051509490.1876@ppc970.osdl.org>
This matches the git extended header git-apply expects to what
is documented.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
# - linus: git-apply: fix rename header parsing
# + (working tree)
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -435,8 +435,8 @@ static int parse_git_header(char *line,
{ "new file mode ", gitdiff_newfile },
{ "copy from ", gitdiff_copysrc },
{ "copy to ", gitdiff_copydst },
- { "rename old ", gitdiff_renamesrc },
- { "rename new ", gitdiff_renamedst },
+ { "rename from ", gitdiff_renamesrc },
+ { "rename to ", gitdiff_renamedst },
{ "similarity index ", gitdiff_similarity },
{ "dissimilarity index ", gitdiff_dissimilarity },
{ "", gitdiff_unrecognized },
^ permalink raw reply
* Re: [PATCH] Fix apply.c to match rename extended header to the document.
From: Linus Torvalds @ 2005-06-05 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8y1o1ltn.fsf_-_@assigned-by-dhcp.cox.net>
On Sun, 5 Jun 2005, Junio C Hamano wrote:
>
> This matches the git extended header git-apply expects to what
> is documented.
Well you also need to fix the tests.
I did it all, and pushed out. And I left git-apply accepting the old
format, at least for a while.
Linus
^ permalink raw reply
* [PATCH-CAREFUL/RENAME] rename git-rpush and git-rpull to git-ssh-push and git-ssh-pull
From: Junio C Hamano @ 2005-06-05 22:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.58.0506051427280.1876@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> However, I've now made "git-apply" fully functional, and as far as I can
LT> tell, it would happily eat this patch. However, it so happens that your
LT> patch conflicts with the other patches sent yesterday, so it won't.
Here is a rebase. To apply with git-apply, you need the "Yes,
sir" patch to grok "rename from/to".
------------
In preparation for 1.0 release, this makes the command names
consistent with others in git-*-pull family.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/git-rpull.txt b/Documentation/git-ssh-pull.txt
similarity index 90%
rename from Documentation/git-rpull.txt
rename to Documentation/git-ssh-pull.txt
--- a/Documentation/git-rpull.txt
+++ b/Documentation/git-ssh-pull.txt
@@ -1,21 +1,21 @@
-git-rpull(1)
-============
+git-ssh-pull(1)
+===============
v0.1, May 2005
NAME
----
-git-rpull - Pulls from a remote repository over ssh connection
+git-ssh-pull - Pulls from a remote repository over ssh connection
SYNOPSIS
--------
-'git-rpull' [-c] [-t] [-a] [-d] [-v] [--recover] commit-id url
+'git-ssh-pull' [-c] [-t] [-a] [-d] [-v] [--recover] commit-id url
DESCRIPTION
-----------
-Pulls from a remote repository over ssh connection, invoking git-rpush on
-the other end.
+Pulls from a remote repository over ssh connection, invoking git-ssh-push
+on the other end.
OPTIONS
-------
diff --git a/Documentation/git-rpush.txt b/Documentation/git-ssh-push.txt
similarity index 71%
rename from Documentation/git-rpush.txt
rename to Documentation/git-ssh-push.txt
--- a/Documentation/git-rpush.txt
+++ b/Documentation/git-ssh-push.txt
@@ -1,19 +1,19 @@
-git-rpush(1)
-============
+git-ssh-push(1)
+===============
v0.1, May 2005
NAME
----
-git-rpush - Helper "server-side" program used by git-rpull
+git-ssh-push - Helper "server-side" program used by git-ssh-pull
SYNOPSIS
--------
-'git-rpush'
+'git-ssh-push'
DESCRIPTION
-----------
-Helper "server-side" program used by git-rpull.
+Helper "server-side" program used by git-ssh-pull.
Author
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -148,7 +148,7 @@ link:git-resolve-script.html[git-resolve
link:git-tag-script.html[git-tag-script]::
An example script to create a tag object signed with GPG
-link:git-rpull.html[git-rpull]::
+link:git-ssh-pull.html[git-ssh-pull]::
Pulls from a remote repository over ssh connection
Interogators:
@@ -156,8 +156,8 @@ Interogators:
link:git-diff-helper.html[git-diff-helper]::
Generates patch format output for git-diff-*
-link:git-rpush.html[git-rpush]::
- Helper "server-side" program used by git-rpull
+link:git-ssh-push.html[git-ssh-push]::
+ Helper "server-side" program used by git-ssh-pull
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -30,7 +30,7 @@ PROG= git-update-cache git-diff-files
git-checkout-cache git-diff-tree git-rev-tree git-ls-files \
git-check-files git-ls-tree git-merge-base git-merge-cache \
git-unpack-file git-export git-diff-cache git-convert-cache \
- git-http-pull git-rpush git-rpull git-rev-list git-mktag \
+ git-http-pull git-ssh-push git-ssh-pull git-rev-list git-mktag \
git-diff-helper git-tar-tree git-local-pull git-write-blob \
git-get-tar-commit-id git-mkdelta git-apply git-stripspace
@@ -105,8 +105,8 @@ git-diff-cache: diff-cache.c
git-convert-cache: convert-cache.c
git-http-pull: http-pull.c pull.c
git-local-pull: local-pull.c pull.c
-git-rpush: rsh.c
-git-rpull: rsh.c pull.c
+git-ssh-push: rsh.c
+git-ssh-pull: rsh.c pull.c
git-rev-list: rev-list.c
git-mktag: mktag.c
git-diff-helper: diff-helper.c
diff --git a/rpull.c b/ssh-pull.c
similarity index 97%
rename from rpull.c
rename to ssh-pull.c
--- a/rpull.c
+++ b/ssh-pull.c
@@ -64,13 +64,13 @@ int main(int argc, char **argv)
arg++;
}
if (argc < arg + 2) {
- usage("git-rpull [-c] [-t] [-a] [-v] [-d] [--recover] commit-id url");
+ usage("git-ssh-pull [-c] [-t] [-a] [-v] [-d] [--recover] commit-id url");
return 1;
}
commit_id = argv[arg];
url = argv[arg + 1];
- if (setup_connection(&fd_in, &fd_out, "git-rpush", url, arg, argv + 1))
+ if (setup_connection(&fd_in, &fd_out, "git-ssh-push", url, arg, argv + 1))
return 1;
if (get_version())
diff --git a/rpush.c b/ssh-push.c
similarity index 93%
rename from rpush.c
rename to ssh-push.c
--- a/rpush.c
+++ b/ssh-push.c
@@ -16,7 +16,7 @@ int serve_object(int fd_in, int fd_out)
do {
size = read(fd_in, sha1 + posn, 20 - posn);
if (size < 0) {
- perror("git-rpush: read ");
+ perror("git-ssh-push: read ");
return -1;
}
if (!size)
@@ -30,7 +30,7 @@ int serve_object(int fd_in, int fd_out)
buf = map_sha1_file(sha1, &objsize);
if (!buf) {
- fprintf(stderr, "git-rpush: could not find %s\n",
+ fprintf(stderr, "git-ssh-push: could not find %s\n",
sha1_to_hex(sha1));
remote = -1;
}
@@ -45,9 +45,9 @@ int serve_object(int fd_in, int fd_out)
size = write(fd_out, buf + posn, objsize - posn);
if (size <= 0) {
if (!size) {
- fprintf(stderr, "git-rpush: write closed");
+ fprintf(stderr, "git-ssh-push: write closed");
} else {
- perror("git-rpush: write ");
+ perror("git-ssh-push: write ");
}
return -1;
}
@@ -71,7 +71,7 @@ void service(int fd_in, int fd_out) {
retval = read(fd_in, &type, 1);
if (retval < 1) {
if (retval < 0)
- perror("rpush: read ");
+ perror("git-ssh-push: read ");
return;
}
if (type == 'v' && serve_version(fd_in, fd_out))
@@ -91,12 +91,12 @@ int main(int argc, char **argv)
arg++;
}
if (argc < arg + 2) {
- usage("git-rpush [-c] [-t] [-a] commit-id url");
+ usage("git-ssh-push [-c] [-t] [-a] commit-id url");
return 1;
}
commit_id = argv[arg];
url = argv[arg + 1];
- if (setup_connection(&fd_in, &fd_out, "git-rpull", url, arg, argv + 1))
+ if (setup_connection(&fd_in, &fd_out, "git-ssh-pull", url, arg, argv + 1))
return 1;
service(fd_in, fd_out);
^ permalink raw reply
* Re: [PATCH-CAREFUL/RENAME] rename git-rpush and git-rpull to git-ssh-push and git-ssh-pull
From: Linus Torvalds @ 2005-06-05 23:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vmzq4zata.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Jun 2005, Junio C Hamano wrote:
>
> Here is a rebase. To apply with git-apply, you need the "Yes,
> sir" patch to grok "rename from/to".
Seems to have applied correctly. Very nice.
Linus
^ permalink raw reply
* Last mile for 1.0
From: Junio C Hamano @ 2005-06-05 23:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506051509490.1876@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> You document the "rename" header as being "rename from/to", which is
LT> sensible, but doesn't match reality. diff.c has "rename old/new". I found
LT> that out the hard way when doing git-apply ;)
The document was cut & paste from the version of apply.c before
you found it out "the hard way", so of course its wording is
sensible ;-) Anyway, I think we settled this part.
There are still some remaining issues before 1.0. The ones I
personally would want to see merged and/or addressed are:
- git-ssh-push documentation updates from Dan Barkalow, which
he mentions in *1*. I am the primarily guilty one about
"other people seem to have missed it".
- "-w heads/master heads/master" extension to the pull family,
again from Dan, mentioned in the same message.
- "--merge-order" extension to the git-rev-list, from Jon
Seymour, last posted as *2*. I have not tried it on
something big (like linux-2.6 repository) and cannot vouch
for its correctness myself, but I find what it claims to do
quite sensible and attractive.
- Tutorials you have been working on. I'd appreciate it if my
earlier "what about cvs annotate" example *3* finds its home
somewhere in that document ;-).
- "What happens when a merge goes wrong" helper script Jeff
wanted to have in *4*.
- Documentation from Jason McMullan for more commands, reminded
by Petr Baudis in *5*.
[References]
*1* <Pine.LNX.4.21.0506031927000.30848-100000@iabervon.org>
*2* <20050605134733.3123.qmail@blackcubes.dyndns.org>
*3* <7vll5s35pd.fsf@assigned-by-dhcp.cox.net>
*4* <42A181C1.3010902@pobox.com>
*5* <20050605204739.GR17462@pasky.ji.cz>
^ permalink raw reply
* Re: [PATCH] Make git-update-cache --force-remove regular
From: Petr Baudis @ 2005-06-05 23:26 UTC (permalink / raw)
To: torvalds; +Cc: git
In-Reply-To: <20050531165243.GD7013@pasky.ji.cz>
Dear diary, on Tue, May 31, 2005 at 06:52:43PM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
> Make the --force-remove flag behave same as --add, --remove and
> --replace. This means I can do
>
> git-update-cache --force-remove -- file1.c file2.c
>
> which is probably saner and also makes it easier to use in cg-rm.
>
> Signed-off-by: Petr Baudis <pasky@ucw.cz>
Can this go in, please? Currently it's the only delta between your and
my git tree, so I'd like to get it merged so that Cogito works with
stock git again.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Last mile for 1.0
From: Junio C Hamano @ 2005-06-05 23:45 UTC (permalink / raw)
To: Jason McMullan; +Cc: git
In-Reply-To: <7vk6l8xue5.fsf_-_@assigned-by-dhcp.cox.net>
I did not mention git-sync by Jason McMullan on my list of "what
I want to have in 1.0", but that was not because I object to the
idea of having a sync mechanism that knows and takes advantage
of how GIT works. Quite the contrary.
I would like to see such a GIT specific smart sync mechanism
some day. git-http-pull lets us use a dumb server and cannot
assume server-side smarts, git-local-pull operates in an
environment where latency does not matter, but git-ssh-pull and
git-sync are solutions for the real network environment where
latency matters, and having a smart sync mechanism is a big win.
I just do not feel, judging from its current protocol command
set, it offers enough improvements over what git-ssh-push/pull
pairs already give us; I'd be happy to be corrected, of course,
if this is a misconception.
^ permalink raw reply
* Re: cg-init bug -- identified and fixed - thanks!
From: Zack Brown @ 2005-06-05 23:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050605201904.GL17462@pasky.ji.cz>
On Sun, Jun 05, 2005 at 10:19:04PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Jun 05, 2005 at 08:29:12PM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > I figured it out.
> >
> > I made a temporary copy of the directory, and kept doing
> >
> > $ rm -rf .git
> > $ rm somerandomfileordir
> > $ cg-init
> > $ cg-status
> >
> > It turned out one of my files had a "'" in the name, i.e.:
> >
> > $ ls
> > Zack's_file
> > $
> >
> > I removed it, and all of a sudden cg-init worked perfectly.
> >
> > Is that a Cogito bug? I would expect git to handle any filename the filesystem
> > itself can handle.
>
> Could you check with the latest Cogito, please?
> (88467971134efddf66793ba44c4ee1ffc7573a0a)
I just tried with fd787bb8d89cdacedc16cfef9dc4feb0cf843def
which is a few patches later than the one you list.
The problem seems to be fixed. Many thanks!
Be well,
Zack
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> -
> 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
--
Zack Brown
^ permalink raw reply
* Re: [PATCH] Make git-update-cache --force-remove regular
From: Linus Torvalds @ 2005-06-05 23:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050605232620.GU17462@pasky.ji.cz>
On Mon, 6 Jun 2005, Petr Baudis wrote:
>
> Can this go in, please? Currently it's the only delta between your and
> my git tree, so I'd like to get it merged so that Cogito works with
> stock git again.
Done.
Linus
^ permalink raw reply
* Re: Last mile for 1.0
From: Linus Torvalds @ 2005-06-06 0:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6l8xue5.fsf_-_@assigned-by-dhcp.cox.net>
On Sun, 5 Jun 2005, Junio C Hamano wrote:
>
> - Tutorials you have been working on. I'd appreciate it if my
> earlier "what about cvs annotate" example *3* finds its home
> somewhere in that document ;-).
My main dislike about that was that I don't think -S is "better" than
annotate as you claim - I think it's different and can be better in many
circumstances, but I don't like the notion of telling a new user "you
don't want annotate, pickaxe is better".
Let's just be upfront about some things being missing, and suggest
alternatives. A lot of times, just "git-whatchanged -p filename" ends up
being sufficient, at other times -S might be.
Finally, please send it as a patch, that way the authorship etc stuff gets
done right.
> - "What happens when a merge goes wrong" helper script Jeff
> wanted to have in *4*.
Does anybody have any suggestions? Preferably with a reasonable
test-case, so that people can try it out.. Maybe just leaving the merge
failures where they are?
Linus
^ permalink raw reply
* Re: [PATCH] Modify git-rev-list ... in merge order [ repost with bug fixes ]
From: Linus Torvalds @ 2005-06-06 0:44 UTC (permalink / raw)
To: jon; +Cc: git, jon.seymour
In-Reply-To: <20050605134733.3123.qmail@blackcubes.dyndns.org>
On Sun, 5 Jun 2005 jon@blackcubes.dyndns.org wrote:
>
> -static void show_commit(struct commit *commit)
> +static int show_commit(struct commit *commit)
Ick. You've mixed "show_commit()" to be three totally independent things
- deciding whether to show at all
- showing the commit in traditional format
- showing the commit tree in the new "break" format
I really hate functions that do totally unrelated things, and I'm so much
happier with the new show_commit() than the old "everything in one big
function" thing, that I'm unhappy about mixing the thing up again.
Please leave show_commit() to just show the commit, and make the other
decisions be independent of that.
Linus
^ permalink raw reply
* [PATCH] git-whatchanged vs "cvs annotate"
From: Junio C Hamano @ 2005-06-06 0:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506051658100.1876@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Let's just be upfront about some things being missing, and suggest
LT> alternatives.
I agree that being honest is good. Something like this?
------------
This adds a section to talk about "cvs annotate".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/cvs-migration.txt | 105 +++++++++++++++++++++++++++++++++++++++
1 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/cvs-migration.txt
@@ -0,0 +1,105 @@
+CVS annotate.
+
+The core GIT itself does not have a "cvs annotate" equivalent.
+It has something that you may want to use when you would use
+"cvs annotate".
+
+Let's step back a bit and think about the reason why you would
+want to do "cvs annotate a-file.c" to begin with.
+
+You would use "cvs annotate" on a file when you have trouble
+with a function (or even a single "if" statement in a function)
+that happens to be defined in the file, which does not do what
+you want it to do. And you would want to find out why it was
+written that way, because you are about to modify it to suit
+your needs, and at the same time you do not want to break its
+current callers. For that, you are trying to find out why the
+original author did things that way in the original context.
+
+Many times, it may be enough to see the commit log messages of
+commits that touch the file in question, possibly along with the
+patches themselves, like this:
+
+ $ git-whatchanged -p a-file.c
+
+This will show log messages and patches for each commit that
+touches a-file.
+
+This, however, may not be very useful when this file has many
+modifications that are not related to the piece of code you are
+interested in. You would see many log messages and patches that
+do not have anything to do with the piece of code you are
+interested in. As an example, assuming that you have this piece
+code that you are interested in in the HEAD version:
+
+ if (frotz) {
+ nitfol();
+ }
+
+you would use git-rev-list and git-diff-tree like this:
+
+ $ git-rev-list HEAD |
+ git-diff-tree --stdin -v -p -S'if (frotz) {
+ nitfol();
+ }'
+
+We have already talked about the "--stdin" form of git-diff-tree
+command that reads the list of commits and compares each commit
+with its parents. The git-whatchanged command internally runs
+the equivalent of the above command, and can be used like this:
+
+ $ git-whatchanged -p -S'if (frotz) {
+ nitfol();
+ }'
+
+When the -S option is used, git-diff-tree command outputs
+differences between two commits only if one tree has the
+specified string in a file and the corresponding file in the
+other tree does not. The above example looks for a commit that
+has the "if" statement in it in a file, but its parent commit
+does not have it in the same shape in the corresponding file (or
+the other way around, where the parent has it and the commit
+does not), and the differences between them are shown, along
+with the commit message (thanks to the -v flag). It does not
+show anything for commits that do not touch this "if" statement.
+
+Also, in the original context, the same statement might have
+appeared at first in a different file and later the file was
+renamed to "a-file.c". CVS annotate would not help you to go
+back across such a rename, but GIT would still help you in such
+a situation. For that, you can give the -C flag to
+git-diff-tree, like this:
+
+ $ git-whatchanged -p -C -S'if (frotz) {
+ nitfol();
+ }'
+
+When the -C flag is used, file renames and copies are followed.
+So if the "if" statement in question happens to be in "a-file.c"
+in the current HEAD commit, even if the file was originally
+called "o-file.c" and then renamed in an earlier commit, or if
+the file was created by copying an existing "o-file.c" in an
+earlier commit, you will not lose track. If the "if" statement
+did not change across such rename or copy, then the commit that
+does rename or copy would not show in the output, and if the
+"if" statement was modified while the file was still called
+"o-file.c", it would find the commit that changed the statement
+when it was in "o-file.c".
+
+[ BTW, the current versions of "git-diff-tree -C" is not eager
+ enough to find copies, and it will miss the fact that a-file.c
+ was created by copying o-file.c unless o-file.c was somehow
+ changed in the same commit.]
+
+You can use the --pickaxe-all flag in addition to the -S flag.
+This causes the differences from all the files contained in
+those two commits, not just the differences between the files
+that contain this changed "if" statement:
+
+ $ git-whatchanged -p -C -S'if (frotz) {
+ nitfol();
+ }' --pickaxe-all
+
+[ Side note. This option is called "--pickaxe-all" because -S
+ option is internally called "pickaxe", a tool for software
+ archaeologists.]
------------
^ permalink raw reply
* [PATCH] Documentation: describe diff tweaking (fix).
From: Junio C Hamano @ 2005-06-06 0:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vr7fg1ofh.fsf@assigned-by-dhcp.cox.net>
I cannot count ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/diffcore.txt b/Documentation/diffcore.txt
--- a/Documentation/diffcore.txt
+++ b/Documentation/diffcore.txt
@@ -45,7 +45,7 @@ the -p option is not used. E.g.
The diffcore mechanism is fed a list of such comparison results
(each of which is called "filepair", although at this point each
of them talks about a single file), and transforms such a list
-into another list. There are currently 7 such transformations:
+into another list. There are currently 6 such transformations:
- diffcore-pathspec
- diffcore-break
^ permalink raw reply
* Re: [PATCH] Modify git-rev-list ... in merge order [ repost with bug fixes ]
From: Jon Seymour @ 2005-06-06 1:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506051741190.1876@ppc970.osdl.org>
On 6/6/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Sun, 5 Jun 2005 jon@blackcubes.dyndns.org wrote:
> >
> > -static void show_commit(struct commit *commit)
> > +static int show_commit(struct commit *commit)
>
> Ick. You've mixed "show_commit()" to be three totally independent things
> - deciding whether to show at all
> - showing the commit in traditional format
> - showing the commit tree in the new "break" format
>
> I really hate functions that do totally unrelated things, and I'm so much
> happier with the new show_commit() than the old "everything in one big
> function" thing, that I'm unhappy about mixing the thing up again.
>
> Please leave show_commit() to just show the commit, and make the other
> decisions be independent of that.
My rationale was to re-use both the filtering logic currently in the
show_commit_list while loop and the display logic, since I need both
in order to maximise compatibility with the standard algorithm.
However, I understand your concerns.
My plan, therefore, is to split the filtering logic from
show_commit_list's while loop into a separate function and create a
third function which calls the filtering logic, then show_commit. I'll
pass a pointer to the third function to sort_list_in_merge_order. I
can leave the show_breaks functionality in show_commit (it is, after
all, display functionality) or I can move it into the third function.
Is that ok by you?
jon.
^ 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