* Re: Git SVN Rebranching Issue
From: Sverre Rabbelier @ 2008-11-04 10:15 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Eric Wong, Matt Kern, git
In-Reply-To: <20081104094224.GC24100@dpotapov.dyndns.org>
On Tue, Nov 4, 2008 at 10:42, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
>> Short answer: you can use grafts to remove parents.
>
> Using grafts requires some cautious, especially when it is used to make
> some commits unreachable, because git gc can remove unreachable commits.
> Also, a repository with grafts cannot be cloned. So using grafts looks
> like more as workaround rather a real solution
I think what was meants is to use grafts and then make them permanent
with 'git filter-branch'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Intensive rename detection
From: Björn Steinbrink @ 2008-11-04 10:47 UTC (permalink / raw)
To: Andrew Arnott; +Cc: Jeff King, Junio C Hamano, Linus Torvalds, git
In-Reply-To: <216e54900811032236l5ae4bde5v16ab6519962e428f@mail.gmail.com>
On 2008.11.03 22:36:42 -0800, Andrew Arnott wrote:
> On Mon, Nov 3, 2008 at 10:16 PM, Jeff King <peff@peff.net> wrote:
> > On Mon, Nov 03, 2008 at 10:02:37PM -0800, Andrew Arnott wrote:
> >
> >> Hmmm.... actually on second run I am still getting the too many files
> >> warning. I put the [diff] section in a ~/.gitconfig file, a
> >> .gitconfig file in the root of my repo, and in the .git/config file,
> >> but none of them seem to get rid of the message.
> >
> > Where are you getting the warning? On "git status"?
> >
> > If so, then this is an instance of the problem I mentioned here:
> >
> > [PATCH v3 7/8] wt-status: load diff ui config
> > 20081026044935.GG21047@coredump.intra.peff.net
>
> Yes, on git status. I'm afraid I don't know how to look up the
> reference you gave.
http://marc.info/?l=git&m=122499658810367&w=2
Björn
^ permalink raw reply
* Re: Fetch via http and proxy which requires authentication
From: Paolo Ciarrocchi @ 2008-11-04 11:13 UTC (permalink / raw)
To: Dilip M; +Cc: Git Mailing List
In-Reply-To: <c94f8e120811030602p57007278p5a2c48ce7663282d@mail.gmail.com>
On Mon, Nov 3, 2008 at 3:02 PM, Dilip M <dilipm79@gmail.com> wrote:
> On Thu, Aug 28, 2008 at 3:43 PM, Paolo Ciarrocchi
> <paolo.ciarrocchi@gmail.com> wrote:
>>> Hi all,
>>> i'm looking for a way to use git behind a corporate proxy which
>>> requires authentication.
>>> i just need to be able to fetch/pull via http.
>>> i'm using git on a win xp box.
>>> Any hint?
>>
>> Yes, google for http_proxy ;-)
>>
>> export http_proxy=http://host:port
>> git clone http://username:password@giturl
>
> I tried setting, export http_proxy=http://<user>:<password>@host:port
>
> But git clone failed!
>
> $git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git
> clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Initialized empty Git repository in /home/dilipm/bin/linux-2.6/.git/
> fatal:
> http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/info/refs
> download error - The requested file was not found
>
> What may the problem? How can debug....
Works for me:
$ git version
git version 1.6.0.2.1172.ga5ed0
I set in the Environment Variables panel:
Variable Value
http_proxy http://ip_of_my_proxy
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Git SVN Rebranching Issue
From: Matt Kern @ 2008-11-04 11:24 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Eric Wong, git
In-Reply-To: <20081104094224.GC24100@dpotapov.dyndns.org>
> > It was actually an intentional design decision on my part preserve
> > parents based on branch name. We would eventually otherwise lose
> > history of the now-deleted branches, as reflogs can expire.
>
> Would it not be better to save the old branch using "@SVN-NUMBER" as
> suffix? Thus, those do not need the old branch can easily delete it.
I would second this approach.
Our svn repository isn't particularly big or old, but if someone were to
make a branch now, there is a fair chance it will have the same name as
an old branch but have absolutely nothing to do with that old branch.
The situation will only get worse as our svn repository grows and more
branches are created/deleted.
Matt
--
Matt Kern
http://www.undue.org/
^ permalink raw reply
* [PATCH 1/3] tag: Do not allow to call "git tag" in more than one operating mode
From: Samuel Tardieu @ 2008-11-04 12:42 UTC (permalink / raw)
To: git
If "git tag -d -l -v ..." is called, only "-l" is honored, which is
arbitrary and wrong.
This patch checks that "git tag" knows in what mode it operates before
performing any operation.
Signed-Off-By: Samuel Tardieu <sam@rfc1149.net>
---
builtin-tag.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 84db156..5ce0e21 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -380,7 +380,11 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
}
if (sign)
annotate = 1;
+ if (argc == 0 && !(delete || verify))
+ list = 1;
+ if (list + delete + verify > 1)
+ usage_with_options(git_tag_usage, options);
if (list)
return list_tags(argv[0], lines);
if (delete)
@@ -406,11 +410,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
}
}
- if (argc == 0) {
- if (annotate)
- usage_with_options(git_tag_usage, options);
- return list_tags(NULL, lines);
- }
tag = argv[0];
object_ref = argc == 2 ? argv[1] : "HEAD";
^ permalink raw reply related
* [PATCH 2/3] tag: Check that options are only allowed in the appropriate mode
From: Samuel Tardieu @ 2008-11-04 12:42 UTC (permalink / raw)
To: git
In-Reply-To: <20081104124207.18273.31679.stgit@arrakis.enst.fr>
"git tag" should not silently accept unrecognized options when operating
in a given mode. For example, "git tag -n 100", which may be a typo for
"git tag -n100", should not silently create a tag named "100".
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
builtin-tag.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 5ce0e21..d339971 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -344,7 +344,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
const char *object_ref, *tag;
struct ref_lock *lock;
- int annotate = 0, sign = 0, force = 0, lines = 0,
+ int annotate = 0, sign = 0, force = 0, lines = -1,
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
@@ -383,10 +383,16 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (argc == 0 && !(delete || verify))
list = 1;
+ if ((annotate || msg.given || msgfile || force) &&
+ (list || delete || verify))
+ usage_with_options(git_tag_usage, options);
+
if (list + delete + verify > 1)
usage_with_options(git_tag_usage, options);
if (list)
- return list_tags(argv[0], lines);
+ return list_tags(argv[0], lines == -1 ? 0 : lines);
+ if (lines != -1)
+ die("-n option is only allowed with -l.");
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
^ permalink raw reply related
* [PATCH 3/3] tag: Add more tests about mixing incompatible modes and options
From: Samuel Tardieu @ 2008-11-04 12:42 UTC (permalink / raw)
To: git
In-Reply-To: <20081104124207.18273.31679.stgit@arrakis.enst.fr>
Signed-Off-By: Samuel Tardieu <sam@rfc1149.net>
---
t/t7004-tag.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index f0edbf1..f377fea 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1090,4 +1090,15 @@ test_expect_success 'filename for the message is relative to cwd' '
git cat-file tag tag-from-subdir-2 | grep "in sub directory"
'
+# mixing modes and options:
+
+test_expect_success 'mixing incompatibles modes and options is forbidden' '
+ test_must_fail git tag -a
+ test_must_fail git tag -l -v
+ test_must_fail git tag -n 100
+ test_must_fail git tag -l -m msg
+ test_must_fail git tag -l -F some file
+ test_must_fail git tag -v -s
+'
+
test_done
^ permalink raw reply related
* RE: why not TortoiseGit
From: Johannes Schindelin @ 2008-11-04 12:52 UTC (permalink / raw)
To: Li Frank; +Cc: Nigel Magnay, Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE961E75EA@zch01exm23.fsl.freescale.net>
Hi,
On Tue, 4 Nov 2008, Li Frank wrote:
> TortoriseGIt should be in windows platform only because it is extension
> of explore.
FYI I completely disagree with this reasoning.
Ciao,
Dscho
^ permalink raw reply
* RE: CRLF support bugs (was: Re: .gitattributes glob matchingbroken)
From: Kelly F. Hickel @ 2008-11-04 12:37 UTC (permalink / raw)
To: Jeff King, Hannu Koivisto; +Cc: git
In-Reply-To: <20081104051432.GD31276@coredump.intra.peff.net>
> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Jeff King
> Sent: Monday, November 03, 2008 11:15 PM
> To: Hannu Koivisto
> Cc: git@vger.kernel.org
> Subject: Re: CRLF support bugs (was: Re: .gitattributes glob
> matchingbroken)
>
> On Mon, Nov 03, 2008 at 05:05:24PM +0200, Hannu Koivisto wrote:
>
<snip>
> > I think CRLF conversion support should have some attribute (be it
> > .gitattributes attribute or something else) that is somehow
> > inherited from the parent repository. It would basically say that
> > "you should use platform's native line end type for text files with
> > this repository and its children". To go with that, one would
> > maybe have a configuration option to tell what that platform
> > default line end type is (just in case someone wants to pretend
> > Cygwin is Unix or something like that).
>
> I think others have complained before about something like this, in
> that
> it really is a _local_ decision and not a _project_ decision to make. I
> am fortunate enough to work exclusively on platforms with sane line
> endings, so I don't know what is normal.
From my point of view, the factoid that a particular file should be subjected to having its line endings munged is a _project_ decision. Whether or not to munge them on any given platform is a _local_ decision.
I work on various UNIXes, Linux, Windows, z/OS, etc, etc, and I want the tool to just do the right thing so that I don't have to think about it on a daily basis.
My $0.02....
-Kelly
>
> But if you really wanted to do such a thing for some set of corporate
> users, maybe it would make sense to have a "clone" hook that runs after
> init and can set up any relevant config (e.g., by copying certain
> config
> values from the parent repo).
>
> -Peff
^ permalink raw reply
* More help needed on merging unrelated repos
From: Christian MICHON @ 2008-11-04 13:14 UTC (permalink / raw)
To: Git Mailing List
Hi,
I previously posted here a question on how to merge unrelated repos,
and I was quite happy with the answer.
git pull repo_name repo_branch
Yet, when I merge these repos (they're unrelated), I'd like to merge
all of them at once.
How do I pull for example 2 repos in 1 command ? I cannot figure out
the exact syntax to use.
I tried:
git pull ../i1 0.5 ../i2 master
git pull ../i1 0.5 -- ../i2 master
I also tried to play with --no-commit and -s to no avail.
Does anyone of you already use this and knows the trick ? Thanks in advance!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Stgit and refresh-temp
From: Jon Smirl @ 2008-11-04 13:37 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas, Git Mailing List
I hit a case when refreshing a buried patch that needed a merge
conflict sorted out.
I'm unable to recover out of the state.
jonsmirl@terra:~/fs$ stg status
A drivers/input/ir/ir-configfs.c
A drivers/input/ir/ir-core.c
A drivers/input/ir/ir.h
C drivers/input/ir/Makefile
D drivers/input/ir-configfs.c
D drivers/input/ir-core.c
D drivers/input/ir.h
M drivers/input/Makefile
M drivers/input/input.c
jonsmirl@terra:~/fs$ gedit drivers/input/Makefile drivers/input/input.c
jonsmirl@terra:~/fs$ gedit drivers/input/ir/Makefile
jonsmirl@terra:~/fs$ stg resolve drivers/input/ir/Makefile
jonsmirl@terra:~/fs$ stg help
usage: stg <command> [options]
Generic commands:
help print the detailed command usage
version display version information
copyright display copyright information
Repository commands:
clone Make a local clone of a remote repository
id Print the git hash value of a StGit reference
Stack (branch) commands:
branch Branch operations: switch, list, create, rename, delete, ...
clean Delete the empty patches in the series
coalesce Coalesce two or more patches into one
commit Permanently store the applied patches into the stack base
float Push patches to the top, even if applied
goto Push or pop patches to the given one
hide Hide a patch in the series
init Initialise the current branch for use with StGIT
log Display the patch changelog
patches Show the applied patches modifying a file
pop Pop one or more patches from the stack
pull Pull changes from a remote repository
push Push one or more patches onto the stack
rebase Move the stack base to another point in history
redo Undo the last undo operation
repair Fix StGit metadata if branch was modified with git commands
reset Reset the patch stack to an earlier state
series Print the patch series
sink Send patches deeper down the stack
top Print the name of the top patch
uncommit Turn regular git commits into StGit patches
undo Undo the last operation
unhide Unhide a hidden patch
Patch commands:
delete Delete patches
edit edit a patch description or diff
export Export patches to a directory
files Show the files modified by a patch (or the current patch)
fold Integrate a GNU diff patch into the current patch
import Import a GNU diff file as a new patch
mail Send a patch or series of patches by e-mail
new Create a new, empty patch
pick Import a patch from a different branch or a commit object
refresh Generate a new commit for the current patch
rename Rename a patch
show Show the commit corresponding to a patch
sync Synchronise patches with a branch or a series
Index/worktree commands:
diff Show the tree diff
resolved Mark a file conflict as solved
status Show the tree status
jonsmirl@terra:~/fs$ stg help coalesce
jonsmirl@terra:~/fs$ stg series
+ Makefile
+ anton_1
+ anton_3
+ add-of_find_i2c_device_by_node
+ jds_platform
+ max9485
+ jds-soc-machine
+ jds-psc-c
+ soc-u32-cleanup
+ jds-audio
+ g_spi_4
+ m_1
+ spi-mmc
+ mpc5200-rtc
+ lirc
+ jds-lirc
> refresh-temp
- jds-lirc-gpt
- jds-lirc-device-tree
- jds-lirc-mce2
jonsmirl@terra:~/fs$ ls
arch Documentation init MAINTAINERS net
samples usr vmlinux.strip.gz
block drivers ipc Makefile patches-master scripts virt
COPYING firmware Kbuild mm patches-save
security vmlinux
CREDITS fs kernel modules.order README sound
vmlinux.bin.gz
crypto include lib Module.symvers REPORTING-BUGS
System.map vmlinux.o
jonsmirl@terra:~/fs$ mv patches-master patches-foo
jonsmirl@terra:~/fs$ stg export
Checking for changes in the working directory ... done
Warning: Local changes in the tree; you might want to commit them first
jonsmirl@terra:~/fs$ stg status
A drivers/input/ir/ir-configfs.c
A drivers/input/ir/ir-core.c
A drivers/input/ir/ir.h
D drivers/input/ir-configfs.c
D drivers/input/ir-core.c
D drivers/input/ir.h
M drivers/input/Makefile
M drivers/input/input.c
M drivers/input/ir/Makefile
jonsmirl@terra:~/fs$ ls patches-master
add-of_find_i2c_device_by_node g_spi_4 jds_platform lirc
max9485 series
anton_1 jds-audio jds-psc-c m_1
mpc5200-rtc soc-u32-cleanup
anton_3 jds-lirc jds-soc-machine Makefile
refresh-temp spi-mmc
jonsmirl@terra:~/fs$ vi patches-master/refresh-temp
jonsmirl@terra:~/fs$ stg series
+ Makefile
+ anton_1
+ anton_3
+ add-of_find_i2c_device_by_node
+ jds_platform
+ max9485
+ jds-soc-machine
+ jds-psc-c
+ soc-u32-cleanup
+ jds-audio
+ g_spi_4
+ m_1
+ spi-mmc
+ mpc5200-rtc
+ lirc
+ jds-lirc
> refresh-temp
- jds-lirc-gpt
- jds-lirc-device-tree
- jds-lirc-mce2
jonsmirl@terra:~/fs$ stg refresh -p jds-lirc
Error: HEAD and top are not the same.
This can happen if you modify a branch with git.
"stg repair --help" explains more about what to do next.
stg refresh: Command aborted (all changes rolled back)
jonsmirl@terra:~/fs$ stg refresh
Error: HEAD and top are not the same.
This can happen if you modify a branch with git.
"stg repair --help" explains more about what to do next.
stg refresh: Command aborted (all changes rolled back)
jonsmirl@terra:~/fs$ stg new foo
Invoking the editor: "vi .stgit-new.txt" ... done
Error: HEAD and top are not the same.
This can happen if you modify a branch with git.
"stg repair --help" explains more about what to do next.
stg new: Command aborted (all changes rolled back)
jonsmirl@terra:~/fs$ stg new foo
Invoking the editor: "vi .stgit-new.txt" ... done
Error: HEAD and top are not the same.
This can happen if you modify a branch with git.
"stg repair --help" explains more about what to do next.
stg new: Command aborted (all changes rolled back)
jonsmirl@terra:~/fs$ stg repair --help
Usage: stg repair
Fix StGit metadata if branch was modified with git commands
Options:
-h, --help show this help message and exit
jonsmirl@terra:~/fs$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Jon Smirl @ 2008-11-04 13:38 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910811040537p4e88c09an94370154eca12778@mail.gmail.com>
jonsmirl@terra:~/fs$ stg version
Stacked GIT 0.14.3.270.g0f36
git version 1.6.0.3.523.g304d0
Python version 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
[GCC 4.3.2]
jonsmirl@terra:~/fs$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: libxdiff and patience diff
From: Johannes Schindelin @ 2008-11-04 14:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: davidel, Git ML
In-Reply-To: <20081104083042.GB3788@artemis.corp>
Hi,
On Tue, 4 Nov 2008, Pierre Habouzit wrote:
> On Tue, Nov 04, 2008 at 05:39:48AM +0000, Johannes Schindelin wrote:
>
> > On Tue, 4 Nov 2008, Pierre Habouzit wrote:
> >
> > > I've been working tonight, trying to make libxdiff support the
> > > patience diff algorithm, but I've totally failed, because I
> > > _thought_ I understood what xdl_split was doing, but it appears I
> > > don't.
> >
> > I thought about it, too, at the GitTogether, although I want to finish
> > my jGit diff first.
> >
> > The main idea I had about patience diff is that you can reuse a lot of
> > functions in libxdiff.
> >
> > But the requirement of taking just unique lines/hashes into account,
> > and _after_ splitting up, _again_ determine uniqueness _just_ in the
> > between-hunk part made me think that it may be wiser to have a
> > separate function for the patience diff stuff.
> >
> > Basically, you would start to have libxdiff split the lines and hash
> > them as normal, but then determine the unique hashes (I'd start with
> > the smaller text, just to have a better chance to end up with unique
> > hashes).
> >
> > Once they are determined, you can search for those exact lines (hash
> > first) in the post-document.
>
> Actually my current implementation just puts all the hashes into an
> array, sorts them by hash (which is O(n log(n)) with the position from
> left or right file it's in, ordered by increasing right position. (and
> the struct is filled with the left pos to -1 if the right pos is set,
> and vice versa).
Yeah, that would be much more efficient using a hash-multiset. Still
linear size (albeit twice as much). And you can already discard double
entries early (although you have to keep one pointer in the hash-multiset
to prevent other identical lines from being misdetected as "unique").
> The I scan the array to find patterns of two consecutive hashes exactly,
> and collapse it into the proper {left pos, right pos} tuple if it was
> indeed a unique line in both files.
>
> This results into an array I sort again by right pos then, and we can
> work on that for the stack sorting, and I do it, and then I have my LCS.
>
>
> This is the complete brute-force algorithm which requires a temporary
> array of the size of the number of lines on the left + the right, and a
> temporary array for the stacks which _may_ end up being as large as the
> smallest number of lines between the left or right file in the worst
> case I'd say (roughly).
>
> Then I just remember a list of split points, and I recurse in all the
> sub splits again. It has a fixed point which may or may not need
> libxdiff recursion in it.
I am not sure that you really end up with patience diff that way. I
_think_ that you need to determine the longest sequence of unique lines
which has the property of being ordered in both texts first, and only
_then_ recurse into the not-yet-handled lines.
> > Once that is done, you'd have to find the longest common subsequence,
> > which you could do using the existing infrastructure, but that would
> > require more work (as we already know the lines are unique).
>
> Patience diff gives you the algorithm to do that, it's pretty simple,
> and is more efficient than the current infrastructure (in time, I don't
> know for space though).
Actually, IIRC it is pretty easy to see that the time complexity is linear
(and therefore, the space complexity, too).
> > After that, you would have to recurse to the same algorithm _between_
> > known chunks. Eventually, that would have to resort to classical
> > libxdiff (if there are no, or not enough, unique lines).
>
> Yeah, that's the point, the problem is, I believe more and more that I
> should prepare the LCS from patience diff in xprepare.c, but I grok
> absolutely nothing at what the chastore_t and similar stuff is. I
> understand it's about hashing, but the exact stuff it does eludes me.
Yes, I do not like the short and unintuitive names either.
AFAIU chastore_t is just a generic extensible array of elements that have
size "isize", and initially there are "icount" of them.
> In fact when I look at the records I have in xdiffi.c I had the
> impression they were already somehow collapsed, which makes it a too
> late point to apply the patience diff ...
AFAICS xdiffi.c contains the classical diff algorithm (incidentally, I the
inventor of that algorithm is about 50 meters away from me at this very
moment). It should not have anything of interest to you, except for the
fall-back case.
So I think that you should add a new file xpatience.c.
In that, I'd implement that hash multi-set, and use a prepared xdfenv_t to
fill it (smaller file first, then you can traverse the other file,
checking for uniqueness in that file and for a match in the other file at
the same time).
You _could_ build the longest list of ordered pairs at the same time, too,
but that may make the code a bit too complex.
Ciao,
Dscho
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Jon Smirl @ 2008-11-04 14:50 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910811040538v604d33e3jf0b312d809630af2@mail.gmail.com>
I think I fixed my tree up. After a stg repair I was able to delete
'refresh-temp' which was empty, then apply the changes to jds-lirc.
It may have been possible to make the merge smarter. The conflicts
were with things in the popped-off patches. Your typical end of file
append merge conflicts.
On Tue, Nov 4, 2008 at 8:38 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> jonsmirl@terra:~/fs$ stg version
> Stacked GIT 0.14.3.270.g0f36
> git version 1.6.0.3.523.g304d0
> Python version 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
> [GCC 4.3.2]
> jonsmirl@terra:~/fs$
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Andrew Arnott @ 2008-11-04 15:12 UTC (permalink / raw)
To: git
In-Reply-To: <216e54900811032334y35ada7daw753c0ad3073c0317@mail.gmail.com>
Nah, that wasn't a false alarm after all. It's happening again, only
this time for dozens of files, and
git rebase --abort
git reset --hard
is not helping.
On Mon, Nov 3, 2008 at 11:34 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> I guess I was still in the middle of a rebase. git rebase --abort
> sort of ultimately fixed it.
>
> On Mon, Nov 3, 2008 at 11:09 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
>> I was just git commit'ing, and then I was doing a git rebase to squash
>> several commits into one when the rebase failed. I then did a
>> git checkout -f master
>> git reset --hard
>> but no matter what I do, git thinks that several files have changed.
>> The diff shows all the lines in these several files removed and then
>> added, yet without any changes made to them. git reset --hard doesn't
>> revert the change. When I jump around history with git checkout these
>> files remain in their "changed" state. I even tried "git clone" to
>> create a whole new repo, but one of these several files STILL
>> registered as changed before I made any changes.
>>
>> Any idea what's wrong and how to recover?
>>
>> Observe the below command buffer: (I can upload my repo so you can
>> clone it and perhaps repro it if you want).
>>
>> Andrew@LACKY /c/git/dotnetoauth
>> $ git status
>> # On branch master
>> # Changed but not updated:
>> # (use "git add <file>..." to update what will be committed)
>> #
>> # modified: tools/Documentation.targets
>> # modified: tools/DotNetOpenAuth.Common.Settings.targets
>> # modified: tools/DotNetOpenAuth.Versioning.targets
>> # modified:
>> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
>> # modified: tools/libcheck.ps1
>> # modified: tools/sandcastle.targets
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Andrew@LACKY /c/git/dotnetoauth
>> $ git reset --hard
>> HEAD is now at 13d37b8 Patching up the bad merges in the phases.
>>
>> Andrew@LACKY /c/git/dotnetoauth
>> $ git status
>> # On branch master
>> # Changed but not updated:
>> # (use "git add <file>..." to update what will be committed)
>> #
>> # modified: tools/Documentation.targets
>> # modified: tools/DotNetOpenAuth.Common.Settings.targets
>> # modified: tools/DotNetOpenAuth.Versioning.targets
>> # modified:
>> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
>> # modified: tools/libcheck.ps1
>> # modified: tools/sandcastle.targets
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>
^ permalink raw reply
* Re: libxdiff and patience diff
From: Pierre Habouzit @ 2008-11-04 15:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: davidel, Git ML
In-Reply-To: <alpine.DEB.1.00.0811041447170.24407@pacific.mpi-cbg.de>
[-- Attachment #1.1: Type: text/plain, Size: 5442 bytes --]
On Tue, Nov 04, 2008 at 02:34:37PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 4 Nov 2008, Pierre Habouzit wrote:
>
> > On Tue, Nov 04, 2008 at 05:39:48AM +0000, Johannes Schindelin wrote:
> >
> > > On Tue, 4 Nov 2008, Pierre Habouzit wrote:
> > >
> > > > I've been working tonight, trying to make libxdiff support the
> > > > patience diff algorithm, but I've totally failed, because I
> > > > _thought_ I understood what xdl_split was doing, but it appears I
> > > > don't.
> > >
> > > I thought about it, too, at the GitTogether, although I want to finish
> > > my jGit diff first.
> > >
> > > The main idea I had about patience diff is that you can reuse a lot of
> > > functions in libxdiff.
> > >
> > > But the requirement of taking just unique lines/hashes into account,
> > > and _after_ splitting up, _again_ determine uniqueness _just_ in the
> > > between-hunk part made me think that it may be wiser to have a
> > > separate function for the patience diff stuff.
> > >
> > > Basically, you would start to have libxdiff split the lines and hash
> > > them as normal, but then determine the unique hashes (I'd start with
> > > the smaller text, just to have a better chance to end up with unique
> > > hashes).
> > >
> > > Once they are determined, you can search for those exact lines (hash
> > > first) in the post-document.
> >
> > Actually my current implementation just puts all the hashes into an
> > array, sorts them by hash (which is O(n log(n)) with the position from
> > left or right file it's in, ordered by increasing right position. (and
> > the struct is filled with the left pos to -1 if the right pos is set,
> > and vice versa).
>
> Yeah, that would be much more efficient using a hash-multiset. Still
> linear size (albeit twice as much). And you can already discard double
> entries early (although you have to keep one pointer in the hash-multiset
> to prevent other identical lines from being misdetected as "unique").
Probably, I just wanted something to work first, and then optimize it
using the proper structure.
> I am not sure that you really end up with patience diff that way. I
> _think_ that you need to determine the longest sequence of unique lines
> which has the property of being ordered in both texts first, and only
> _then_ recurse into the not-yet-handled lines.
I must have been using really bad english because it's what I do ;)
> > > Once that is done, you'd have to find the longest common subsequence,
> > > which you could do using the existing infrastructure, but that would
> > > require more work (as we already know the lines are unique).
> >
> > Patience diff gives you the algorithm to do that, it's pretty simple,
> > and is more efficient than the current infrastructure (in time, I don't
> > know for space though).
>
> Actually, IIRC it is pretty easy to see that the time complexity is linear
> (and therefore, the space complexity, too).
Well the space complexity of the patience diff would be linear too for
me, though I'm afraid that the current state of my implementation has a
big factor front ;)
> > In fact when I look at the records I have in xdiffi.c I had the
> > impression they were already somehow collapsed, which makes it a too
> > late point to apply the patience diff ...
>
> AFAICS xdiffi.c contains the classical diff algorithm (incidentally, I the
> inventor of that algorithm is about 50 meters away from me at this very
> moment). It should not have anything of interest to you, except for the
> fall-back case.
>
> So I think that you should add a new file xpatience.c.
>
> In that, I'd implement that hash multi-set, and use a prepared xdfenv_t to
> fill it (smaller file first, then you can traverse the other file,
> checking for uniqueness in that file and for a match in the other file at
> the same time).
>
> You _could_ build the longest list of ordered pairs at the same time, too,
> but that may make the code a bit too complex.
Well, technically, if I'm correct, xdiffi.c already has a pruned list of
hashed (I suppose ->ha is a hash value somehow ?) lines (pruned from
lines without a match left or right), and I was massaging that. Though
it absolutely fails so I fear I didn't understand what the ha stuff is
for real.
Attached is my current work (YES it is horrible, it's WIP), probably
most of it can be put in an xpatience.c file, but still, I absolutely
don't understand what gets wrong. On the simple example from
glandium.org it _looks_ like it catches the "unique" include line fine,
but somehow not.
The nasty thing about the patience diff is that it still needs the usual
diff algorithm once it has split the file into chunks separated by
"unique lines". So you cannot make really independant stuff. What I
could do is put most of the xpatience diff into xpatience.c but it would
still have to use some functions from xdiffi.c that are currently
private, so it messes somehow the files more than it's worth IMHO.
Anyways, I'm waiting for a client to finally setup his network for the
test I'm supposed to do right now, I'll try to have a closer look
tonight...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #1.2: wip.patch --]
[-- Type: text/plain, Size: 8642 bytes --]
diff --git a/diff.c b/diff.c
index f644947..0901cdc 100644
--- a/diff.c
+++ b/diff.c
@@ -2447,6 +2447,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
options->xdl_opts |= XDF_IGNORE_WHITESPACE_CHANGE;
else if (!strcmp(arg, "--ignore-space-at-eol"))
options->xdl_opts |= XDF_IGNORE_WHITESPACE_AT_EOL;
+ else if (!strcmp(arg, "--patience"))
+ options->xdl_opts |= XDF_USE_PATIENCE;
/* flags options */
else if (!strcmp(arg, "--binary")) {
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 84fff58..bba915c 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -32,6 +32,7 @@ extern "C" {
#define XDF_IGNORE_WHITESPACE (1 << 2)
#define XDF_IGNORE_WHITESPACE_CHANGE (1 << 3)
#define XDF_IGNORE_WHITESPACE_AT_EOL (1 << 4)
+#define XDF_USE_PATIENCE (1 << 5)
#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL)
#define XDL_PATCH_NORMAL '-'
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 9d0324a..1a5b13a 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -37,8 +37,235 @@ typedef struct s_xdpsplit {
int min_lo, min_hi;
} xdpsplit_t;
+typedef struct s_xduniqmatch {
+ struct s_xduniqmatch *next;
+ long i1, i2, len;
+} xduniqmatch_t;
+
+typedef struct s_xdp_ha {
+ struct s_xdp_ha *up, *down;
+ struct s_xdp_ha *left;
+ long ha;
+ long off1;
+ long off2;
+} xdp_ha_t;
+
+
+static xduniqmatch_t *xdl_uniq_match_alloc(long i1, long i2, long len)
+{
+ xduniqmatch_t *match = xdl_malloc(sizeof(xduniqmatch_t));
+ if (match) {
+ match->next = NULL;
+ match->i1 = i1;
+ match->i2 = i2;
+ match->len = len;
+ }
+ return match;
+}
+
+static xduniqmatch_t *xdl_uniq_popfree(xduniqmatch_t *lst)
+{
+ xduniqmatch_t *next = lst->next;
+ xdl_free(lst);
+ return next;
+}
+
+static int xdp_ha_cmp_by_ha(const void *a1, const void *a2)
+{
+ const xdp_ha_t *ha1 = a1;
+ const xdp_ha_t *ha2 = a2;
+ if (ha1->ha == ha2->ha) {
+ return ha1->off2 - ha2->off2;
+ }
+ return ha1->ha - ha2->ha;
+}
+
+static int xdp_ha_cmp_by_off2(const void *a1, const void *a2)
+{
+ const xdp_ha_t *ha1 = a1;
+ const xdp_ha_t *ha2 = a2;
+ return ha2->off2 - ha1->off2;
+}
+
+static int patience_bisect_stack(xdp_ha_t **stacks, long len, long off1)
+{
+ long l = 0, r = len;
+
+ while (l < r) {
+ long i = (r + l) / 2;
+
+ if (off1 < stacks[i]->off1) {
+ l = i + 1;
+ } else {
+ r = i;
+ }
+ }
+ return l;
+}
+
+static int xdl_patience_split_aux(xduniqmatch_t *lcs, xdp_ha_t *ha)
+{
+ xduniqmatch_t *tmp;
+
+ while (ha) {
+ tmp = xdl_uniq_match_alloc(ha->off1, ha->off2, 1);
+ if (!tmp)
+ return -1;
+ tmp->next = lcs->next;
+ lcs->next = tmp;
+ lcs = tmp;
+
+ while ((ha = ha->down ? ha->down : ha->left)) {
+ if (lcs->i1 + lcs->len + 1 == ha->off1 && lcs->i2 + lcs->len + 1 == ha->off2) {
+ lcs->len++;
+ continue;
+ }
+ break;
+ }
+ }
+ return 0;
+}
+
+static int xdl_patience_split(unsigned long const *ha1, unsigned long const *ha2,
+ xduniqmatch_t *begin, xduniqmatch_t *end)
+{
+ xdp_ha_t *recs;
+ long off1 = begin->i1 + begin->len, lim1 = end->i1;
+ long off2 = begin->i2 + begin->len, lim2 = end->i2;
+ long len, i, j, uniq;
+
+ len = lim1 - off1 + lim2 - off2;
+ recs = (xdp_ha_t *)xdl_malloc(sizeof(xdp_ha_t) * len);
+ if (recs == NULL)
+ return -1;
+
+ for (i = 0, j = off1; j < lim1 - off1; j++, i++) {
+ recs[i].ha = ha1[j];
+ recs[i].off1 = j;
+ recs[i].off2 = -1;
+ recs[i].up = recs[i].down = recs[i].left = NULL;
+ }
+ for (j = off2; j < lim2; j++, i++) {
+ recs[i].ha = ha2[j];
+ recs[i].off1 = -1;
+ recs[i].off2 = j;
+ recs[i].up = recs[i].down = recs[i].left = NULL;
+ }
+
+ qsort(recs, len, sizeof(xdp_ha_t), xdp_ha_cmp_by_ha);
+
+ uniq = 0;
+ for (i = 0; i < len - 1; ) {
+ long ha = recs[i].ha;
+
+ if (ha != recs[i + 1].ha) {
+ i++;
+ continue;
+ }
+
+ if (i < len - 2 && ha == recs[i + 2].ha) {
+ i += 3;
+ while (i < len - 1 && recs[i].ha == ha && i < len - 1) {
+ i++;
+ }
+ continue;
+ }
+
+ if (recs[i].off2 < 0 && recs[i + 1].off1 < 0) {
+ long a, b;
+ recs[uniq].ha = ha;
+ a = recs[uniq].off1 = recs[i].off1;
+ b = recs[uniq].off2 = recs[i + 1].off2;
+ uniq++;
+ }
+ i += 2;
+ }
+
+ if (uniq) {
+ xdp_ha_t **stacks;
+ long alloc, len;
+
+ qsort(recs, uniq, sizeof(xdp_ha_t), xdp_ha_cmp_by_off2);
+
+ alloc = xdl_bogosqrt(uniq);
+ stacks = xdl_malloc(sizeof(xdp_ha_t *) * alloc);
+ if (stacks == NULL)
+ goto error;
+ len = 1;
+ stacks[0] = recs;
+
+ for (i = 1; i < uniq; i++) {
+ long off1 = recs[i].off1;
+ long k;
+
+ if (off1 < stacks[len - 1]->off1) {
+ if (len >= alloc) {
+ alloc *= 2;
+ stacks = xdl_realloc(stacks, sizeof(xdp_ha_t *) * alloc);
+ if (!stacks)
+ goto error;
+ }
+ stacks[k = len++] = NULL;
+ } else {
+ k = patience_bisect_stack(stacks, len - 1, off1);
+ }
+
+ if (k > 0) {
+ recs[i].left = stacks[k - 1];
+ }
+ if (stacks[k]) {
+ stacks[k]->down = &recs[i];
+ recs[i].up = stacks[k];
+ }
+ stacks[k] = &recs[i];
+ }
+
+ if (xdl_patience_split_aux(begin, stacks[len - 1]) < 0) {
+ xdl_free(stacks);
+ goto error;
+ }
+
+ xdl_free(stacks);
+ }
+
+ xdl_free(recs);
+ return 0;
+
+error:
+ xdl_free(recs);
+ return -1;
+}
+
+static int xdl_patience_lcs(xdfenv_t *xe, xduniqmatch_t *begin, xduniqmatch_t *end)
+{
+ unsigned long const *ha1 = xe->xdf1.ha, *ha2 = xe->xdf2.ha;
+ long off1 = begin->i1 + begin->len, lim1 = end->i1;
+ long off2 = begin->i2 + begin->len, lim2 = end->i2;
+ xduniqmatch_t *next;
+
+ for (; off1 < lim1 && off2 < lim2 && ha1[off1] == ha2[off2]; off1++, off2++);
+ for (; off1 < lim1 && off2 < lim2 && ha1[lim1 - 1] == ha2[lim2 - 1]; lim1--, lim2--);
+
+ begin->len += off1 - begin->i1;
+ end->len += end->i1 - lim1;
+ end->i1 = lim1;
+ end->i2 = lim2;
+
+ if (off1 == lim1 || off2 == lim2)
+ return 0;
+
+ if (xdl_patience_split(ha1, ha2, begin, end))
+ return -1;
+
+ for (next = begin->next; next != end; begin = next, next = begin->next) {
+ if (xdl_patience_lcs(xe, begin, next) < 0)
+ return -1;
+ }
+
+ return 0;
+}
static long xdl_split(unsigned long const *ha1, long off1, long lim1,
unsigned long const *ha2, long off2, long lim2,
@@ -321,13 +548,13 @@ int xdl_recs_cmp(diffdata_t *dd1, long off1, long lim1,
return 0;
}
-
int xdl_do_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdfenv_t *xe) {
long ndiags;
long *kvd, *kvdf, *kvdb;
xdalgoenv_t xenv;
diffdata_t dd1, dd2;
+ int need_min = (xpp->flags & XDF_NEED_MINIMAL) != 0;
if (xdl_prepare_env(mf1, mf2, xpp, xe) < 0) {
@@ -364,12 +591,54 @@ int xdl_do_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
dd2.rchg = xe->xdf2.rchg;
dd2.rindex = xe->xdf2.rindex;
- if (xdl_recs_cmp(&dd1, 0, dd1.nrec, &dd2, 0, dd2.nrec,
- kvdf, kvdb, (xpp->flags & XDF_NEED_MINIMAL) != 0, &xenv) < 0) {
+ if (xpp->flags & XDF_USE_PATIENCE) {
+ xduniqmatch_t *lcs;
+ long i1, i2;
+
+ lcs = xdl_uniq_match_alloc(0, 0, 0);
+ if (!lcs)
+ goto error;
+ lcs->next = xdl_uniq_match_alloc(xe->xdf1.nreff, xe->xdf2.nreff, 0);
+ if (!lcs->next || xdl_patience_lcs(xe, lcs, lcs->next) < 0) {
+ while ((lcs = xdl_uniq_popfree(lcs)));
+ goto error;
+ }
- xdl_free(kvd);
- xdl_free_env(xe);
- return -1;
+ i1 = i2 = lcs->len;
+ if (lcs->len) {
+ fprintf(stderr, "skip %ld:%ld -> %ld:%ld\n",
+ lcs->i1, i1, lcs->i2, i2);
+ }
+
+ while ((lcs = xdl_uniq_popfree(lcs))) {
+ fprintf(stderr, "usual %ld:%ld -> %ld:%ld\n",
+ i1, lcs->i1, i2, lcs->i2);
+ fprintf(stderr, "l/r: %ld / %ld\n",
+ xe->xdf1.rindex[lcs->i1],
+ xe->xdf2.rindex[lcs->i2]);
+ if (xdl_recs_cmp(&dd1, i1, lcs->i1, &dd2, i2, lcs->i2,
+ kvdf, kvdb, need_min, &xenv) < 0) {
+ while ((lcs = xdl_uniq_popfree(lcs)));
+ goto error;
+ }
+ i1 = lcs->i1 + lcs->len;
+ i2 = lcs->i2 + lcs->len;
+ if (lcs->len) {
+ fprintf(stderr, "skip %ld:%ld -> %ld:%ld (len %ld)\n",
+ lcs->i1, i1, lcs->i2, i2, lcs->len);
+ fprintf(stderr, "l/r: %ld / %ld\n",
+ xe->xdf1.rindex[lcs->i1 + lcs->len],
+ xe->xdf2.rindex[lcs->i2 + lcs->len]);
+ }
+ }
+ } else {
+ if (xdl_recs_cmp(&dd1, 0, dd1.nrec, &dd2, 0, dd2.nrec,
+ kvdf, kvdb, need_min, &xenv) < 0) {
+error:
+ xdl_free(kvd);
+ xdl_free_env(xe);
+ return -1;
+ }
}
xdl_free(kvd);
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: libxdiff and patience diff
From: Johannes Schindelin @ 2008-11-04 15:57 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: davidel, Git ML
In-Reply-To: <20081104152351.GA21842@artemis.corp>
Hi,
On Tue, 4 Nov 2008, Pierre Habouzit wrote:
> The nasty thing about the patience diff is that it still needs the usual
> diff algorithm once it has split the file into chunks separated by
> "unique lines".
Actually, it should try to apply patience diff again in those chunks,
separately.
> So you cannot make really independant stuff. What I could do is put most
> of the xpatience diff into xpatience.c but it would still have to use
> some functions from xdiffi.c that are currently private, so it messes
> somehow the files more than it's worth IMHO.
I think it is better that you use the stuff from xdiffi.c through a well
defined interface, i.e. _not_ mess up the code by mingling it together
with the code in xdiffi.c. The code is hard enough to read already.
Oh, BTW, "ha" is a hash of the lines which is used to make the line
matching more performant. You will see a lot of "ha" comparisons before
actually calling xdl_recmatch() for that reason. Incidentally, this is
also the hash that I'd use for the hash multi-set I was referring to.
Oh, and I am not sure that it is worth your time trying to get it to run
with the linear list, since you cannot reuse that code afterwards, and
have to spend the same amount of time to redo it with the hash set.
I am awfully short on time, so it will take some days until I can review
what you have already, unfortunately.
Ciao,
Dscho
^ permalink raw reply
* Re: libxdiff and patience diff
From: Pierre Habouzit @ 2008-11-04 16:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: davidel, Git ML
In-Reply-To: <alpine.DEB.1.00.0811041650510.24407@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]
On Tue, Nov 04, 2008 at 03:57:44PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 4 Nov 2008, Pierre Habouzit wrote:
>
> > The nasty thing about the patience diff is that it still needs the usual
> > diff algorithm once it has split the file into chunks separated by
> > "unique lines".
>
> Actually, it should try to apply patience diff again in those chunks,
> separately.
yes it's what I do, but this has a fixed point as soon as you don't find
unique lines between the new found ones, or that that space is "empty".
E.g. you could have the two following hunks:
File A File B
1 2
2 1
1 2
2 1
1 2
2
1
The simple leading/trailing reduction will do nothing, and you don't
have any shared unique lines, on that you must apply the usual diff
algorithm.
> > So you cannot make really independant stuff. What I could do is put most
> > of the xpatience diff into xpatience.c but it would still have to use
> > some functions from xdiffi.c that are currently private, so it messes
> > somehow the files more than it's worth IMHO.
>
> I think it is better that you use the stuff from xdiffi.c through a well
> defined interface, i.e. _not_ mess up the code by mingling it together
> with the code in xdiffi.c. The code is hard enough to read already.
Hmmm. I'll see to that later, once I have something that works.
> Oh, BTW, "ha" is a hash of the lines which is used to make the line
> matching more performant. You will see a lot of "ha" comparisons before
> actually calling xdl_recmatch() for that reason. Incidentally, this is
> also the hash that I'd use for the hash multi-set I was referring to.
Yeah, that's what I assumed it would be.
> Oh, and I am not sure that it is worth your time trying to get it to run
> with the linear list, since you cannot reuse that code afterwards, and
> have to spend the same amount of time to redo it with the hash set.
Having the linear list (actually an array) work would show me I hook at
the proper place. Replacing a data structure doesn't makes me afraid
because I've split the functions properly.
> I am awfully short on time, so it will take some days until I can review
> what you have already, unfortunately.
NP, it was just in case, because I'm horribly stuck with that code right
now ;)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [take 2] git send-email updates
From: Pierre Habouzit @ 2008-11-04 16:24 UTC (permalink / raw)
To: git
In-Reply-To: <1225450632-7230-1-git-send-email-madcoder@debian.org>
[PATCH 1/5] git send-email: make the message file name more specific.
self described
[PATCH 2/5] git send-email: interpret unknown files as revision lists
All unknown arguments are passed to git-format-patch at once,
checking for possible file/rev conflicts and dying in that case,
like Junio suggested.
[PATCH 3/5] git send-email: add --annotate option
same as before.
[PATCH 4/5] git send-email: ask less questions when --compose is used.
same as before, with an update wrt empty bodies. Still doesn't grok
To/Cc/Bcc. I would be really glad if a patch to deal with it was
appended to that series, but a patch that deals with Header
continuations well.
[PATCH 5/5] git send-email: turn --compose on when more than one patch.
This patch is probably controversial. I propose it not because I'm
lazy, I now have a 'git send' alias for the task that expands to
'send-email -C -C -M -n --annotate --compose --to'. I propose it
because I believe it's a good thing to make people write about their
stuff when there is a series and not a single patch. If they still
don't want to, they just have to clear the mail buffer at once.
The drawback is that it _may_ break some scripts, those people would
have to pass --no-compose to their send-email call to fix the
scripts.
I wouldn't complain if the patch gets dropped.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
^ permalink raw reply
* [PATCH 1/5] git send-email: make the message file name more specific.
From: Pierre Habouzit @ 2008-11-04 16:24 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225815858-30617-1-git-send-email-madcoder@debian.org>
This helps editors choosing their syntax hilighting properly.
Also make the file live under the git directory.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-send-email.perl | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94ca5c8..aaace02 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -124,9 +124,6 @@ my $auth;
sub unique_email_list(@);
sub cleanup_compose_files();
-# Constants (essentially)
-my $compose_filename = ".msg.$$";
-
# Variables we fill in automatically, or via prompting:
my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$author,$sender,$smtp_authpass,$compose,$time);
@@ -149,6 +146,7 @@ if ($@) {
# Behavior modification variables
my ($quiet, $dry_run) = (0, 0);
+my $compose_filename = $repo->repo_path() . "/.gitsendemail.msg.$$";
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Pierre Habouzit @ 2008-11-04 16:24 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225815858-30617-2-git-send-email-madcoder@debian.org>
Filter out all the arguments git-send-email doesn't like to a
git format-patch command, that dumps its content to a safe directory.
Barf when a file/revision conflict occurs.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 28 ++++++++++++++++++++++++----
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 82f5056..4654d4f 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -8,7 +8,7 @@ git-send-email - Send a collection of patches as emails
SYNOPSIS
--------
-'git send-email' [options] <file|directory> [... file|directory]
+'git send-email' [options] <file|directory|rev-list options>...
DESCRIPTION
diff --git a/git-send-email.perl b/git-send-email.perl
index aaace02..c29868a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -22,8 +22,11 @@ use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
use Term::ANSIColor;
+use File::Temp qw/ tempdir /;
use Git;
+Getopt::Long::Configure qw/ pass_through /;
+
package FakeTerm;
sub new {
my ($class, $reason) = @_;
@@ -38,7 +41,7 @@ package main;
sub usage {
print <<EOT;
-git send-email [options] <file | directory>...
+git send-email [options] <file | directory | rev-list options >
Composing:
--from <str> * Email From:
@@ -363,10 +366,22 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
($sender) = expand_aliases($sender) if defined $sender;
+sub check_file_rev_conflict($) {
+ my $f = shift;
+ if ($repo->command('rev-parse', '--verify', '--quiet', $f)) {
+ die("revision/filename conflict on `$f'");
+ }
+}
+
# Now that all the defaults are set, process the rest of the command line
# arguments and collect up the files that need to be processed.
-for my $f (@ARGV) {
- if (-d $f) {
+my @rev_list_opts;
+while (my $f = pop @ARGV) {
+ if ($f eq "--") {
+ push @rev_list_opts, "--", @ARGV;
+ @ARGV = ();
+ } elsif (-d $f) {
+ check_file_rev_conflict($f);
opendir(DH,$f)
or die "Failed to opendir $f: $!";
@@ -374,12 +389,17 @@ for my $f (@ARGV) {
sort readdir(DH);
closedir(DH);
} elsif (-f $f or -p $f) {
+ check_file_rev_conflict($f);
push @files, $f;
} else {
- print STDERR "Skipping $f - not found.\n";
+ push @rev_list_opts, $f;
}
}
+if (@rev_list_opts) {
+ push @files, $repo->command('format-patch', '-o', tempdir(CLEANUP => 1), @rev_list_opts);
+}
+
if ($validate) {
foreach my $f (@files) {
unless (-p $f) {
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/5] git send-email: add --annotate option
From: Pierre Habouzit @ 2008-11-04 16:24 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225815858-30617-3-git-send-email-madcoder@debian.org>
This allows to review every patch (and fix various aspects of them, or
comment them) in an editor just before being sent. Combined to the fact
that git send-email can now process revision lists, this makes git
send-email and efficient way to review and send patches interactively.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-send-email.txt | 11 +++++++++++
git-send-email.perl | 26 ++++++++++++++++++++++++--
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 4654d4f..39d6da9 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -37,6 +37,11 @@ The --bcc option must be repeated for each user you want on the bcc list.
+
The --cc option must be repeated for each user you want on the cc list.
+--annotate::
+ Review each patch you're about to send in an editor. The setting
+ 'sendemail.multiedit' defines if this will spawn one editor per patch
+ or one for all of them at once.
+
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
@@ -204,6 +209,12 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+sendemail.multiedit::
+ If true (default), a single editor instance will be spawned to edit
+ files you have to edit (patches when '--annotate' is used, and the
+ summary when '--compose' is used). If false, files will be edited one
+ after the other, spawning a new editor each time.
+
Author
------
diff --git a/git-send-email.perl b/git-send-email.perl
index c29868a..d0c5a41 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -50,6 +50,7 @@ git send-email [options] <file | directory | rev-list options >
--bcc <str> * Email Bcc:
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
+ --annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
Sending:
@@ -129,7 +130,8 @@ sub cleanup_compose_files();
# Variables we fill in automatically, or via prompting:
my (@to,@cc,@initial_cc,@bcclist,@xh,
- $initial_reply_to,$initial_subject,@files,$author,$sender,$smtp_authpass,$compose,$time);
+ $initial_reply_to,$initial_subject,@files,
+ $author,$sender,$smtp_authpass,$annotate,$compose,$time);
my $envelope_sender;
@@ -151,6 +153,17 @@ if ($@) {
my ($quiet, $dry_run) = (0, 0);
my $compose_filename = $repo->repo_path() . "/.gitsendemail.msg.$$";
+# Handle interactive edition of files.
+my $multiedit;
+my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+sub do_edit {
+ if (defined($multiedit) && !$multiedit) {
+ map { system('sh', '-c', $editor.' "$@"', $editor, $_); } @_;
+ } else {
+ system('sh', '-c', $editor.' "$@"', $editor, @_);
+ }
+}
+
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
@@ -180,6 +193,7 @@ my %config_settings = (
"aliasesfile" => \@alias_files,
"suppresscc" => \@suppress_cc,
"envelopesender" => \$envelope_sender,
+ "multiedit" => \$multiedit,
);
# Handle Uncouth Termination
@@ -222,6 +236,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-ssl" => sub { $smtp_encryption = 'ssl' },
"smtp-encryption=s" => \$smtp_encryption,
"identity=s" => \$identity,
+ "annotate" => \$annotate,
"compose" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
@@ -515,7 +530,12 @@ EOT
close(C);
my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
- system('sh', '-c', $editor.' "$@"', $editor, $compose_filename);
+
+ if ($annotate) {
+ do_edit($compose_filename, @files);
+ } else {
+ do_edit($compose_filename);
+ }
open(C2,">",$compose_filename . ".final")
or die "Failed to open $compose_filename.final : " . $!;
@@ -564,6 +584,8 @@ EOT
}
@files = ($compose_filename . ".final", @files);
+} elsif ($annotate) {
+ do_edit(@files);
}
# Variables we set as part of the loop over files
--
1.5.6.5
^ permalink raw reply related
* [PATCH 4/5] git send-email: ask less questions when --compose is used.
From: Pierre Habouzit @ 2008-11-04 16:24 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225815858-30617-4-git-send-email-madcoder@debian.org>
When --compose is used, we can grab the From/Subject/In-Reply-To from the
edited summary, let it be so and don't ask the user silly questions.
The summary templates gets quite revamped, and includes the list of
patches subjects that are going to be sent with this batch.
When having a body full of empty lines, the summary isn't sent. Document
that in the git-send-email manpage fully.
Note: It doesn't deal with To/Cc/Bcc yet.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-send-email.txt | 9 ++
git-send-email.perl | 177 ++++++++++++++++++++++---------------
2 files changed, 114 insertions(+), 72 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 39d6da9..e06db6b 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -45,6 +45,15 @@ The --cc option must be repeated for each user you want on the cc list.
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
++
+When compose is in used, git send-email gets less interactive will use the
+values of the headers you set there. If the body of the email (what you type
+after the headers and a blank line) only contains blank (or GIT: prefixed)
+lines, the summary won't be sent, but git-send-email will still use the
+Headers values if you don't removed them.
++
+If it wasn't able to see a header in the summary it will ask you about it
+interactively after quitting your editor.
--from::
Specify the sender of the emails. This will default to
diff --git a/git-send-email.perl b/git-send-email.perl
index d0c5a41..fd72127 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -433,6 +433,108 @@ if (@files) {
usage();
}
+sub get_patch_subject($) {
+ my $fn = shift;
+ open (my $fh, '<', $fn);
+ while (my $line = <$fh>) {
+ next unless ($line =~ /^Subject: (.*)$/);
+ close $fh;
+ return "GIT: $1\n";
+ }
+ close $fh;
+ die "No subject line in $fn ?";
+}
+
+if ($compose) {
+ # Note that this does not need to be secure, but we will make a small
+ # effort to have it be unique
+ open(C,">",$compose_filename)
+ or die "Failed to open for writing $compose_filename: $!";
+
+
+ my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
+ my $tpl_subject = $initial_subject || '';
+ my $tpl_reply_to = $initial_reply_to || '';
+
+ print C <<EOT;
+From $tpl_sender # This line is ignored.
+GIT: Lines beginning in "GIT: " will be removed.
+GIT: Consider including an overall diffstat or table of contents
+GIT: for the patch you are writing.
+GIT:
+GIT: Clear the body content if you don't wish to send a summary.
+From: $tpl_sender
+Subject: $tpl_subject
+In-Reply-To: $tpl_reply_to
+
+EOT
+ for my $f (@files) {
+ print C get_patch_subject($f);
+ }
+ close(C);
+
+ my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+
+ if ($annotate) {
+ do_edit($compose_filename, @files);
+ } else {
+ do_edit($compose_filename);
+ }
+
+ open(C2,">",$compose_filename . ".final")
+ or die "Failed to open $compose_filename.final : " . $!;
+
+ open(C,"<",$compose_filename)
+ or die "Failed to open $compose_filename : " . $!;
+
+ my $need_8bit_cte = file_has_nonascii($compose_filename);
+ my $in_body = 0;
+ my $summary_empty = 1;
+ while(<C>) {
+ next if m/^GIT: /;
+ if ($in_body) {
+ $summary_empty = 0 unless (/^\n$/);
+ } elsif (/^\n$/) {
+ $in_body = 1;
+ if ($need_8bit_cte) {
+ print C2 "MIME-Version: 1.0\n",
+ "Content-Type: text/plain; ",
+ "charset=utf-8\n",
+ "Content-Transfer-Encoding: 8bit\n";
+ }
+ } elsif (/^MIME-Version:/i) {
+ $need_8bit_cte = 0;
+ } elsif (/^Subject:\s*(.+)\s*$/i) {
+ $initial_subject = $1;
+ my $subject = $initial_subject;
+ $_ = "Subject: " .
+ ($subject =~ /[^[:ascii:]]/ ?
+ quote_rfc2047($subject) :
+ $subject) .
+ "\n";
+ } elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
+ $initial_reply_to = $1;
+ next;
+ } elsif (/^From:\s*(.+)\s*$/i) {
+ $sender = $1;
+ next;
+ } elsif (/^(?:To|Cc|Bcc):/i) {
+ print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
+ next;
+ }
+ print C2 $_;
+ }
+ close(C);
+ close(C2);
+
+ if ($summary_empty) {
+ print "Summary email is empty, skpping it\n";
+ $compose = -1;
+ }
+} elsif ($annotate) {
+ do_edit(@files);
+}
+
my $prompting = 0;
if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
@@ -477,17 +579,6 @@ sub expand_aliases {
@initial_cc = expand_aliases(@initial_cc);
@bcclist = expand_aliases(@bcclist);
-if (!defined $initial_subject && $compose) {
- while (1) {
- $_ = $term->readline("What subject should the initial email start with? ", $initial_subject);
- last if defined $_;
- print "\n";
- }
-
- $initial_subject = $_;
- $prompting++;
-}
-
if ($thread && !defined $initial_reply_to && $prompting) {
while (1) {
$_= $term->readline("Message-ID to be used as In-Reply-To for the first email? ", $initial_reply_to);
@@ -514,64 +605,6 @@ if (!defined $smtp_server) {
}
if ($compose) {
- # Note that this does not need to be secure, but we will make a small
- # effort to have it be unique
- open(C,">",$compose_filename)
- or die "Failed to open for writing $compose_filename: $!";
- print C "From $sender # This line is ignored.\n";
- printf C "Subject: %s\n\n", $initial_subject;
- printf C <<EOT;
-GIT: Please enter your email below.
-GIT: Lines beginning in "GIT: " will be removed.
-GIT: Consider including an overall diffstat or table of contents
-GIT: for the patch you are writing.
-
-EOT
- close(C);
-
- my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
-
- if ($annotate) {
- do_edit($compose_filename, @files);
- } else {
- do_edit($compose_filename);
- }
-
- open(C2,">",$compose_filename . ".final")
- or die "Failed to open $compose_filename.final : " . $!;
-
- open(C,"<",$compose_filename)
- or die "Failed to open $compose_filename : " . $!;
-
- my $need_8bit_cte = file_has_nonascii($compose_filename);
- my $in_body = 0;
- while(<C>) {
- next if m/^GIT: /;
- if (!$in_body && /^\n$/) {
- $in_body = 1;
- if ($need_8bit_cte) {
- print C2 "MIME-Version: 1.0\n",
- "Content-Type: text/plain; ",
- "charset=utf-8\n",
- "Content-Transfer-Encoding: 8bit\n";
- }
- }
- if (!$in_body && /^MIME-Version:/i) {
- $need_8bit_cte = 0;
- }
- if (!$in_body && /^Subject: ?(.*)/i) {
- my $subject = $1;
- $_ = "Subject: " .
- ($subject =~ /[^[:ascii:]]/ ?
- quote_rfc2047($subject) :
- $subject) .
- "\n";
- }
- print C2 $_;
- }
- close(C);
- close(C2);
-
while (1) {
$_ = $term->readline("Send this email? (y|n) ");
last if defined $_;
@@ -583,9 +616,9 @@ EOT
exit(0);
}
- @files = ($compose_filename . ".final", @files);
-} elsif ($annotate) {
- do_edit(@files);
+ if ($compose > 0) {
+ @files = ($compose_filename . ".final", @files);
+ }
}
# Variables we set as part of the loop over files
--
1.5.6.5
^ permalink raw reply related
* [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Pierre Habouzit @ 2008-11-04 16:24 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <1225815858-30617-5-git-send-email-madcoder@debian.org>
Automatically turn --compose on when there is more than one patch, and
that the output is a tty.
Do not print the list of files sent anymore in that case, as the list is
shown in the summary editor.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-send-email.perl | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index fd72127..3c7818f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -51,7 +51,7 @@ git send-email [options] <file | directory | rev-list options >
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
--annotate * Review each patch that will be sent in an editor.
- --compose * Open an editor for introduction.
+ --[no-]compose * Open an editor for introduction.
Sending:
--envelope-sender <str> * Email envelope sender.
@@ -237,7 +237,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-encryption=s" => \$smtp_encryption,
"identity=s" => \$identity,
"annotate" => \$annotate,
- "compose" => \$compose,
+ "compose!" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
@@ -425,7 +425,11 @@ if ($validate) {
}
if (@files) {
- unless ($quiet) {
+ if (!defined($compose) && -t STDOUT) {
+ # turn $compose on if there is more than one file
+ $compose = $#files;
+ }
+ unless ($quiet || $compose) {
print $_,"\n" for (@files);
}
} else {
--
1.5.6.5
^ permalink raw reply related
* [PATCH] Add git-gui--askpass to git.spec.in
From: Yutaka Kanemoto @ 2008-11-04 17:15 UTC (permalink / raw)
To: git, gitster
'make rpm' will fail because git-gui--askpass is not listed in git.spec.in.
At least, I was able to create rpm using below patch.
Best regards,
Yutaka KANEMOTO
---
git.spec.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index 6733b6f..bf7fa63 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -167,6 +167,7 @@ rm -rf $RPM_BUILD_ROOT
%files gui
%defattr(-,root,root)
%{_libexecdir}/git-core/git-gui
+%{_libexecdir}/git-core/git-gui--askpass
%{_libexecdir}/git-core/git-citool
%{_datadir}/git-gui/
%{!?_without_docs: %{_mandir}/man1/git-gui.1*}
--
1.6.0.3.613.g9f8f13.dirty
^ permalink raw reply related
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