* Re: [RFC] git-gui window layout
From: Johannes Sixt @ 2007-10-12 10:00 UTC (permalink / raw)
To: Adam Piatyszek; +Cc: git
In-Reply-To: <470F3516.7020606@users.sourceforge.net>
Adam Piatyszek schrieb:
> Dear Giters,
>
> I would like you to comment on my idea to change, or at least add a
> possibility to change, the current layout of git-gui window.
> [...]
>
> +-------------+----------------------------+---+
> | | |###|
> | | commit log |###|
> | staged +----------------------------+---+
> | | |
> | | |
> +----- 1 -----+ |
> | | diff output |
> | 2 |
> | unstaged | |
> | | |
> | | |
> +-------------+--------------------------------+
May I point you to
http://repo.or.cz/w/git-gui.git?a=commitdiff;h=a0592d3f5746b41c60fee71dd8d2d27b5c813907
which was committed 5 hours ago.
Except that it has Unstaged above Staged and Diff above Commit, which IMHO
is much more natural.
-- Hannes
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Simon Sasburg @ 2007-10-12 9:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, Thomas Harning Jr., git
In-Reply-To: <8c5c35580710120126x51c300bfu4345b8c6315d953c@mail.gmail.com>
On 10/12/07, Lars Hjemli <lh@elementstorage.no> wrote:
> On 10/12/07, Simon Sasburg <simon.sasburg@gmail.com> wrote:
> > On 10/11/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > We did not even find a way to post patches via gmail's web interface, not
> > > without severely damaging the patches.
> >
> > Oh? Turning off Rich formatting and copy/pasting the patch from my
> > editor worked for me.
>
> The problem occurs when gmail decides to wrap the lines in the patch
> (max 72 chars per line, I guess).
>
> --
> larsh
>
Ah, good to know, then.
^ permalink raw reply
* git-fast-import crashes
From: Shun Kei Leung @ 2007-10-12 9:42 UTC (permalink / raw)
To: git
Hi all,
I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4. When I tried
to run `git-p4 rebase', it failed with a broken pipe to
`git-fast-import'. I gather the following from GDB. I am kind of
stuck. Does anyone have any idea what's going on?
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x64617469
in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
701 off_t win_off = win->offset;
(gdb) bt
#0 in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
#1 0x0000a7b0 in use_pack (p=0x500740, w_cursor=0xbfffd328,
offset=3501, left=0xbfffd2c8) at sha1_file.c:728
#2 0x0000aaa0 in unpack_object_header (p=0x64617461, w_curs=0x0,
curpos=0xbfffd330, sizep=0xbffff4ec) at sha1_file.c:1329
#3 0x0000e17c in unpack_entry (p=0x500740, obj_offset=3501,
type=0xbffff4e8, sizep=0xbffff4ec) at sha1_file.c:1591
#4 0x0000dc8c in read_packed_sha1 (sha1=0x64617461 <Address
0x64617461 out of bounds>, type=0xbffff4e8, size=0xbffff4ec) at
sha1_file.c:1811
#5 0x0000dd90 in read_sha1_file (sha1=0xbffff4f0
")S??=?P\r?6[?w?S[\021\004??", type=0xbffff4e8, size=0xbffff4ec) at
sha1_file.c:1877
#6 0x0000e020 in read_object_with_reference (sha1=0x100950b
")S??=?P\r?6[?w?S[\021\004??", required_type_name=0x0,
size=0xbffff578, actual_sha1_return=0x100950b
")S??=?P\r?6[?w?S[\021\004??") at sha1_file.c:1906
#7 0x0000450c in cmd_from_existing (b=0x10094c0) at fast-import.c:1922
#8 0x00004b3c in cmd_from (b=0x10094c0) at fast-import.c:1965
#9 0x000078a0 in cmd_new_commit () at fast-import.c:2044
#10 0x000088f0 in main (argc=213252, argv=0xbffff838) at fast-import.c:2329
(gdb) print win
$1 = (struct pack_window *) 0x5004d0
(gdb) print *win
$2 = {
next = 0x64617461,
base = 0x20333936 <Address 0x20333936 out of bounds>,
offset = 22523564414626158,
len = 1685026675,
last_used = 795894075,
inuse_cnt = 0
}
Regards,
Kevin Leung
^ permalink raw reply
* [RFC] git-gui window layout
From: Adam Piatyszek @ 2007-10-12 8:49 UTC (permalink / raw)
To: git
Dear Giters,
I would like you to comment on my idea to change, or at least add a
possibility to change, the current layout of git-gui window.
Nowadays there is a tendency to produce wide screens for laptops and
even standalone LCD monitors. One can safely assume that the minimum
reasonable horizontal resolution of a screen is at least 1024 pixels (I
do not expect anyone using git-gui with 800x600 resolution).
Moreover, most popular window managers decreases the vertical dimension
of a desktop by using horizontally-oriented panels (e.g. KDE, Gnome,
XFCE4, etc.)
The current layout of git-gui window covering the whole desktop area on
a typical WXGA (1280x800) laptop LCD display is thus:
+----------+-----------------------------------+
| | |
| staged | unstaged |
| | |
+----------+----------------+------------------+
|### commit log | EMPTY |
|### | |
+---------------------------+------------------+
| |
| diff output |
| |
+----------------------------------------------+
In my opinion, the staged, unstaged and diff areas are usually used for
displaying things that are taller than wider (e.g. a list of files,
patches of well structured code, which is usually < 80 columns). The
commit log window is also designed for text narrower than < 80 cols.
Therefore in my opinion it might be more useful to restructure this
layout to something like this:
+-------------+----------------------------+---+
| | |###|
| | commit log |###|
| staged +----------------------------+---+
| | |
| | |
+----- 1 -----+ |
| | diff output |
| 2 |
| unstaged | |
| | |
| | |
+-------------+--------------------------------+
Buttons (rescan, push, commit, etc.) are denoted here as ###. Besides
the walls denoted as 1 and 2 should be movable so one could adjust the
size of staged/unstaged and diff areas.
The minimum width of diff window would be limited by the commit log
window width (I propose 80 colums) plus the size of the buttons.
Unfortunately, I do not nothing about TCL/TK programming, so I even did
not tried to analyse the code of git-gui. Therefore I am not sure if
such a restructure is easy to implement.
Anyway I hope for your comments to this idea.
BR,
/Adam
--
.:. Adam Piatyszek - "ediap" .:. JID: ediap(at)jabber.org .:.
.:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:.
^ permalink raw reply
* Re: Status of kha/experimental
From: Catalin Marinas @ 2007-10-12 8:56 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <20071012074323.GB17403@diana.vm.bytemark.co.uk>
On 12/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-11 21:38:12 +0100, Catalin Marinas wrote:
>
> > I'll try - let's say we freeze it starting with the coming Monday
> > (what's currently in kha/safe will be merged anyway) and aim to
> > release 0.14 in about 3 weeks (or as soon as we fix the major bugs).
>
> Do you have a list of the bugs you'd like to see fixed before the
> release? (I don't, I'm not organized. :-) )
https://gna.org/bugs/?group=stgit. All of them, if possible :-). If
you happen to work on any of them, change the "assigned to" filed so
that we don't duplicate the effort.
--
Catalin
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Lars Hjemli @ 2007-10-12 8:26 UTC (permalink / raw)
To: Simon Sasburg; +Cc: Johannes Schindelin, Thomas Harning Jr., git
In-Reply-To: <981e6de60710120027j5f390a9tbe2a4c76db9ed06d@mail.gmail.com>
On 10/12/07, Simon Sasburg <simon.sasburg@gmail.com> wrote:
> On 10/11/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > We did not even find a way to post patches via gmail's web interface, not
> > without severely damaging the patches.
>
> Oh? Turning off Rich formatting and copy/pasting the patch from my
> editor worked for me.
The problem occurs when gmail decides to wrap the lines in the patch
(max 72 chars per line, I guess).
--
larsh
^ permalink raw reply
* Re: Status of kha/experimental
From: Karl Hasselström @ 2007-10-12 7:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0710111338u109aa304o6ba9c886a42c2e24@mail.gmail.com>
On 2007-10-11 21:38:12 +0100, Catalin Marinas wrote:
> I'll try - let's say we freeze it starting with the coming Monday
> (what's currently in kha/safe will be merged anyway) and aim to
> release 0.14 in about 3 weeks (or as soon as we fix the major bugs).
Do you have a list of the bugs you'd like to see fixed before the
release? (I don't, I'm not organized. :-) )
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Simon Sasburg @ 2007-10-12 7:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Harning Jr., git
In-Reply-To: <Pine.LNX.4.64.0710111704570.4174@racer.site>
On 10/11/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> We did not even find a way to post patches via gmail's web interface, not
> without severely damaging the patches.
Oh? Turning off Rich formatting and copy/pasting the patch from my
editor worked for me.
^ permalink raw reply
* Re: yet another workflow question...
From: Andy Parkins @ 2007-10-12 7:25 UTC (permalink / raw)
To: git; +Cc: Jing Xue, Patrick Doyle
In-Reply-To: <20071011164019.3n4l3rayckck8c4w@intranet.digizenstudio.com>
On Thursday 2007 October 11, Jing Xue wrote:
> Quoting Andy Parkins <andyparkins@gmail.com>:
> > - Mobility. This one is a bit distributed, but I hope you'll let
> > me have it.
> > I often do work on my desktop at home, my desktop at work and my
> > laptop. By setting my remotes up correctly in git it's really easy to
> > walk to another system and pick up exactly where I left off from the
> > other computer. More importantly though, when you accidentally make
> > changes in two places, there is no danger of data loss.
>
> To extend on this point, after picking up the randomly checked-in save
> point on another computer, the save point itself can be easily
> git-reset'ed. So there won't be commits like "it's utter broken but i
> got to go home" polluting the history. I find that extremely handy.
Absolutely; in fact I've had times when I've done things like this:
git merge laptop-branch
git merge home-branch
git reset HEAD^^
That is to say, I'm not interested in documenting the merges, I just want to
bring a set of changes from different places together ready for some proper
commits, which of course can be done really easily with git add -i.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* push fails with unexpected 'matches more than one'
From: Steffen Prohaska @ 2007-10-12 6:59 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
This adds a test case for unambigous local match but multiple remote
matches. To me, it is unexpected that a ref that is perfectly defined
on the local side fails with 'matches more than one'.
The following rule could solve this:
A ref shall first be unambigously resolved on the local side, and its
full name should be used for matching on the remote side.
For example 'frotz' resolves locally to 'heads/refs/frotz'.
Therefore pretend the user had typed 'heads/refs/frotz'.
But maybe there is some hidden secret about the current rules that
I do not see.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
t/t5516-fetch-push.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index ca46aaf..f249216 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -244,4 +244,12 @@ test_expect_success 'push with colon-less refspec (4)' '
'
+test_expect_success 'push with colon-less refspec (locally unambigous)' '
+
+ mk_test heads/frotz heads/t/frotz &&
+ git branch -f frotz master &&
+ git push testrepo frotz
+
+'
+
test_done
--
1.5.3.4.219.gd0b2
^ permalink raw reply related
* Re: [PATCH] Fixing path quoting issues
From: Johannes Sixt @ 2007-10-12 6:43 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: David Kastrup, git, Junio C Hamano
In-Reply-To: <63D5CE5B-51DD-4017-B2E2-2ADC5DCBE849@steelskies.com>
Jonathan del Strother schrieb:
>
> On 11 Oct 2007, at 21:53, David Kastrup wrote:
>
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> Jonathan del Strother schrieb:
>>>> How are you going to test that git works on paths with spaces if the
>>>> test suite doesn't run there?
>>>
>>> By writing a specific test?
>>
>> This is going to be much less thorough. And it does no harm if the
>> test scripts demonstrate defensive programming.
>
> I would also point out that most tests have already been written to
> handle this case - ones that don't quote their paths are in the minority.
Actually, reconsidering your proposed patch, there are only a handful of
problematic cases, namely those where the test script is quoted with
double-quotes, like this:
test_expect_success 'load repository with strange names' "
- svnadmin load -q $rawsvnrepo < ../t9115/funky-names.dump &&
+ svnadmin load -q '$rawsvnrepo' < ../t9115/funky-names.dump &&
start_httpd
"
The problem is that here $rawsvnrepo will be expanded before the entire test
script is passed as argument to test_expect_success. Consider the case where
$rawsvnrepo contains a single-quote (say, a directory named "Joe's git"):
then the 'eval' inside test_expect_success sees a syntax error. The proper
change is:
test_expect_success 'load repository with strange names' "
- svnadmin load -q $rawsvnrepo < ../t9115/funky-names.dump &&
+ svnadmin load -q \"\$rawsvnrepo\" < ../t9115/funky-names.dump &&
start_httpd
"
So, what I think you should do is:
1. Submit the change to git-rebase.sh in a separate patch.
2. Fix the patch for the double-quoted test scriptlets.
That should remove all my concerns.
-- Hannes
^ permalink raw reply
* Re: RCS keyword expansion
From: Peter Karlsson @ 2007-10-12 5:27 UTC (permalink / raw)
Cc: git
In-Reply-To: <20071011192103.GD2804@steel.home>
Alex Riesen:
> That's confusing. If your web site is just a checkout, what is the "make
> install" for?
Exactly. That's what I wondering.
> If it is a repo, you have the version information anyway, and at all
> times.
Yes, but not embedded in the page in a format that is visible to the
visitor. For CVS I use something like this:
<p class="date">$Date$</p>
to embed the last update time into the page.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: RCS keyword expansion
From: Peter Karlsson @ 2007-10-12 5:26 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.64.0710112144380.4174@racer.site>
Johannes Schindelin:
> The problem is this: for efficiency, git does not change files which have
> not changes between the last version checked out (whatever that is) and
> the current version.
>
> This seems counterintuitive to people coming from SVN/CVS: they expect
> _every_ file to be touched when checking out.
No? That would just be strange. Only the files that are actually changed
should be updated, no others. A $Date$ or $Id$ will show the last
time/commit that specific file was changed, not the latest global state (I
guess the fact that most modern VCSs have global state makes this a bit more
difficult to achieve, in RCS/CVS/PVCS and others the change history is local
to a file and thus it is trivial to find the large change for that
particular file).
> As Randal already suggested: if you need something like this, you better
> have a build procedure which replaced $Date$ _at a given time_ (make
> install) with the current date.
But that's not what I want. Then my build procedure would need to do a "git
status", or whatever you use to get the last commit information about a
file, on each file that is changed and is to be installed. It would be a lot
easier if that was done already on checkout through some kind of hook.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Martin Langhoff @ 2007-10-12 4:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Harning Jr., git
In-Reply-To: <Pine.LNX.4.64.0710111704570.4174@racer.site>
On 10/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I, for one, am totally opposed to this split. All too often valuable
> _user_ discussions turn into _technical_ discussions, and thence into a
> throwing back and forth patches.
<aol>mee too! - I think it's the kind of development culture that
Linus tries to foster, and I suspect Junio likes too: "talk in
patches" which is a lot more productive than "talk like a pirate",
bikeshedding and other maladies that can fester in mailing lists.
So no split for me ;-) We have the additional alibi that git users are
supposed to be programmers.
m
^ permalink raw reply
* Re: [PATCH - amended] git-gui: update Italian translation
From: Shawn O. Pearce @ 2007-10-12 4:15 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paolo Ciarrocchi, git, Johannes Schindelin
In-Reply-To: <200710102218.23482.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
...
> So here it is. (Sent as an attachment because I fear mangling, sorry).
...
> Subject: [PATCH] git-gui: update Italian translation
>
> An Italian glossary was also added. Some changes:
> * commit (verb): (creare una) nuova revisione
> * commit (noun): revisione
> * checkout: attivazione
> * tracking branch: duplicato locale di ramo remoto
> * repository: archivio
> * some terms are used with more consistency
Thanks. I saw no further discussion on this thread so I have applied
the attached patch as-is. It will be in my repo.or.cz tree in a
couple of hours.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Fixed crash in fetching remote tags when there is not tags.
From: Shawn O. Pearce @ 2007-10-12 4:07 UTC (permalink / raw)
To: Alex Riesen
Cc: Jeff King, Väinö Järvelä, git, Junio C Hamano
In-Reply-To: <20071010212735.GB16635@steel.home>
Alex Riesen <raa.lkml@gmail.com> wrote:
> Still, I'd suggest move the test into the caller, firstly because it
> is the only place that special. Also, I can't think of a proper reason
> to add a NULL ref to a reflist, and so the crashing tail_link_ref will
> help us find the callers which use tail_link_ref incorrectly
> (illogically too).
>
> As the result of patter expansion can be NULL (empty pattern, as it
> seems), lets just check for it. I parked the patch below locally.
>
> diff --git a/remote.c b/remote.c
> index 5e92378..58d63ed 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -884,7 +884,8 @@ int get_fetch_map(struct ref *remote_refs,
> rm->peer_ref->name);
> }
>
> - tail_link_ref(ref_map, tail);
> + if (ref_map)
> + tail_link_ref(ref_map, tail);
>
> return 0;
> }
I disagree with Alex's argument above, because the result of the
pattern expansion can be NULL due to a pattern that matched nothing
from the remote. This can easily happen if the user originally
configured "remote.$name.fetch = +refs/heads/subdir/*:..." and
then the remote deletes all branches from refs/heads/subdir at some
point in the future.
I think the above patch is the only thing to do here. Perhaps Alex
can write up a formal patch and send it to back to the list and CC
Lars Hjemli <hjemli@gmail.com> so he can put it into the patch queue.
--
Shawn.
^ permalink raw reply
* Re: How to have multiple working copy directories use the same repository?
From: Shawn O. Pearce @ 2007-10-12 3:52 UTC (permalink / raw)
To: Alex Riesen, Bill Priest; +Cc: git
In-Reply-To: <20071011190025.GC2804@steel.home>
Alex Riesen <raa.lkml@gmail.com> wrote:
> Bill Priest, Thu, Oct 11, 2007 20:10:50 +0200:
> > I've looked at the "git for CVS users" section in
> > the docs and this appears to create two repositories.
> > Is there a way to have two working directories that
> > utilize the same repository?
>
> Look for "alternates" in git's documentation. But read all the
> warnings regarding git-gc and git-prune. Make a note of ".keep" files.
Really I think Bill wants the contrib/workdir/git-new-workdir script.
Its downside is that it makes heavy use of symlinks under the
.git directory for the secondary working directories, and you do
have to watch out for committing changes to a branch when more
than one working directory has that branch as its current branch.
But otherwise it works very well for this use case.
Also you may get a few warnings from your HEAD reflog saying objects
no longer exist when you do a git-gc within a working directory.
This can happen for example if you use `git rebase -i` in a working
directory a few times and then later run git-gc from a different
working directory. But since its just intermediate rebase state
its probably not that big of a deal to have it go missing.
You shouldn't run `git gc --prune` if any of the working directories
has staged but uncommitted changes in them. Such changes are held
in the working directory's index, which will not be considered
as reachable (as it isn't visible to git-gc) and the objects will
be pruned. That would not too be pleasant to debug.
Heh. As you can see it has some "issues" with its use. Its a very
powerful tool, but it does give you more than enough room to shoot
yourself in the foot. Using it is like tieing a gun to your ankle,
keeping it aimed at your big toe at all times, with a string tied
to your wrist and the gun's trigger. Reach too far and *bam*.
Which is why its still in contrib status.
--
Shawn.
^ permalink raw reply
* RE: Is it possible for git to support binary differencing for binary files?
From: franky @ 2007-10-12 3:04 UTC (permalink / raw)
To: 'Lars Hjemli'; +Cc: git
In-Reply-To: <8c5c35580710111027t127fe9d5qe098d5372783b0@mail.gmail.com>
This is also useful. 3x. However, git-gc is what I want.
-----Original Message-----
From: Lars Hjemli [mailto:hjemli@gmail.com]
Sent: Friday, October 12, 2007 1:27 AM
To: 银平
Cc: git@vger.kernel.org
Subject: Re: Is it possible for git to support binary differencing for
binary files?
On 10/11/07, 银平 <yinping@kooxoo.com> wrote:
> Storing binary files as deltas is helpful to keep source and binary files
> together and in sync So is it possible for git to do that as svn. This is
> my only pain when using git.
Could 'git diff --binary' and 'git apply --binary' be what you're looking
for?
--
larsh
^ permalink raw reply
* RE: Is it possible for git to support binary differencing for binary files?
From: franky @ 2007-10-12 3:01 UTC (permalink / raw)
To: 'Jean-Luc Herren'; +Cc: git
In-Reply-To: <470E633D.8060107@gmx.ch>
git-gc works perfectly! Thanks all very much.
-----Original Message-----
From: Jean-Luc Herren [mailto:jlh@gmx.ch]
Sent: Friday, October 12, 2007 1:54 AM
To: 银平
Cc: git@vger.kernel.org
Subject: Re: Is it possible for git to support binary differencing for
binary files?
银平 wrote:
> Hi.
> Storing binary files as deltas is helpful [...] So is it
> possible for git to do that as svn. This is my only pain when
> using git.
Yes, and git does this already in pack files. Maybe you're not
seeing it because you haven't packed anything yet. Try to run
'git gc'.
jlh
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Baz @ 2007-10-11 22:53 UTC (permalink / raw)
To: Thomas Harning Jr.; +Cc: git
In-Reply-To: <e47324780710110857s472bf099u3e350d17a2c29f78@mail.gmail.com>
On 11/10/2007, Thomas Harning Jr. <harningt@gmail.com> wrote:
> I use gmail as my mail client and it doesn't grok 'PATCH' filters
> (primarily the case of the word).
>
> Are there any of you using Gmail that has managed to get around this issue....?
Try this in the 'has the words' box (the whole thing):
to:git@vger.kernel.org -("+++ b" subject:"[PATCH")
Obviously get rid of the '-' for the other filter you'll want. Patches
that lead to discussion will probably get both tags. The "+++ b" is so
you don't class mails that don't have a patch in the body as patch
mails.
> Perhaps we should have a separate mailing list for patches vs discussion.
>
> --
> Thomas Harning Jr.
> -
> 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
>
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Linus Torvalds @ 2007-10-11 22:33 UTC (permalink / raw)
To: Sam Vilain; +Cc: martin f krafft, git discussion list
In-Reply-To: <470E9AD5.2090002@vilain.net>
On Fri, 12 Oct 2007, Sam Vilain wrote:
>
> 1. do a --cherry-pick rev-list on just the file being merged and see if
> all the changes on one side disappear, in which case just take the result.
>
> 2. see if the files were identical at some point, in which case use a
> new merge base for that file based on the changes since that revision.
>
> I actually thought #2 was already the way recursive worked!
Actually, I think both of these are fundamentally wrong.
The reason is that you talk about "the file".
Anything that is based on per-file heuristics is going to mean that you
use a history that is not necessarily compatible with the _other_ files in
the project.
I agree 100% that per-file history information is going to find more
things to merge automatically. But the point I was trying to make was that
"automatic merges" aren't always *good*.
I realize that pretty much every single theoretical merge algorithm out
there tries to make merges happen automatically as much as possible, but
they all en dup having strange issues.
For example, take a patch that cherry-picked into mainline from a
development branch, but that partly depended on some support-feature that
wasn't in mainline yet. So then there is another patch that removes part
of that patch from mainline. So mainline is fine.
Now, three months later, the development branch is stable, and is fully
merged. What happens?
Git will largely get this right. Git will look at the last *global* common
base, and will just look at the contents, and do a reasonable job. Yes,
there will probably be conflicts (because both the development branch and
the mainline ended up touching the same parts of the files thanks to the
cherry-pick, and yet mainline has some added hacks on top to disable it),
but on the whole that's exactly what you want!
(Alternatively, maybe the "remove the part that wasn't supported yet"
ended up meaning that that particular part of the patch was excised
entirely from mainline, and there was no conflict at all, and git just
merged the new stuff from the development branch cleanly! So I'm not
saying that it *has* to conflict, I'm just saying that it might have).
In other words: git always "does the right thing". Assuming both branches
are stable and working, git does a very reasonable thing. It's obviously
not always the thing people may *want*, but it's guaranteed to be a
reasonable and simple guess, and there's no way it's "too clever for its
own good, and just screwed the pooch entirely".
In contrast, your suggested merge strategy would be HORRIBLY BROKEN!
Why? Because it doesn't look at the *common* history to the project, it
looks at some per-file state that is totally bogus and has no relevance.
Think it through: what happens if there were files with the same content
(because of the cherry-pick), and then the file history for one of the
branches was later changed to disable something because the support for it
wasn't in the "whole history"?
Right: the final merge will contain that change! Because there as a time
where the file was identical (the cherry-pick), so you're taking all the
later changes to that file (the undo)!
Notice? Totally the wrong thing to do!
So this is a classic case of trying to make "easier" merges, but where the
whole approach is totally broken! You simply MUST NOT add logic like that.
It's a lot better to give a conflict, than to try to be "clever", and
silently do the wrong thing.
Yes, you can be really stupid, and silently do the wrong thing too, but if
you're stupid, at least the "silent wrong thing" is never really subtle,
it's pretty much guaranteed to easily explainable. And the good news is
that you didn't have a complicated and fragile algorithm just to get the
wrong answer.
(Put another way: if you are always going to have situations where you get
the wrong answer, you'd better take the simple and stupid algorithm,
because people are more likely to then be able to _predict_ that wrong
answer and are thus more ready to handle it!)
So being clever really is the wrong thing to do. And using history that
isn't global and true history (ie just looking at one file, and deciding
that matching that one file "means" something) is fundamnetally broken.
In fact, in general, individual pieces of history are totally worthless.
The fact that some individual change was done in one branch doesn't really
tell you *anything*. The reason that change was done may be implied by all
the previous changes, or conversely, later changes may have undone the
change, so any merge algorithm that starts to look at individual commits
is likely to be pure and utter crap - exactly because it's starting to
make decisions based on local information that may not be valid in the big
picture.
(Where the "big picture" may be either about "space" - other files - or
about "time" - other commits, that simply mean that the individual changes
of one commit are meaningless on their own).
Btw, one thing to note is how well the simple and stupid git merge
strategy works. It turns out that doing things with the "big picture"
model actually does work really well. People think that they need
"finegrained history" to make good merges, but I think most people who
have actually done a fair number of merges with git have noticed that it's
actually pretty dang painless.
But to be honest, there are cases where git isn't being very helpful. In
particular, I think there *are* things that git could probably be more
helpful with, but looking at local history is not one of them, I think.
So here are some suggestions on things I think we could improve on:
- I think it would be wonderful to have a helper tool for handling
conflicts.
In particular, while I don't think per-file history is good for
resolving conflicts *automatically*, I actually do think that per-file
history can be a good way to *manually* resolve conflicts.
In other words, it you have a conflict, I think it would be wonderful
to have some git-gui-like thing that can show the history (with
patches) for that file, and basically combine a three-way graphical
merge *with* some per-commit information where you can say "choose the
thing that that commit did for this conflict".
So I think git already has tools to help resolve conflicts, and I
personally love doing "gitk --merge" or "git log -p --merge" when a
conflict does happen, but I think some smart GUI person could do
something even much better!
And notice how I think that it's *really* wrong to use per-file history
automatically, but that I think it's not wrong at all to use it when
there's a human that says "ok, obviously pick that case". Things that
are horrible when they cause subtle and automatic resolves can be very
good when they cause subtle resolves that a human looked at!
- I suspect we have issues with common whitespace changes, where we again
could probably help people resolve whitespace changes etc better.
Again, I don't think those are necessarily things you want to do
automatically, but I know from personal experience that handling things
like one side having done a re-indent can be *really* annoying, just
because you end up doing tons of mindless stuff when you fix up all the
totally idiotic and usually trivial conflicts.
.. and I'm sure there are other things we could do better too, but the
above two are things that while they haven't happened for me for the
kernel (probably because we have learnt how to not cause them over the
years), I've seen them in other places.
And yes, the above two suggestions fall solidly in the "conflicts aren't
bad per se, but you want to make the tool really help you resolve them!"
camp.
Linus
^ permalink raw reply
* [PATCH] fix contrib/hooks/post-receive-email hooks.recipients error message
From: Jeff Muizelaar @ 2007-10-11 21:49 UTC (permalink / raw)
To: git; +Cc: Andy Parkins
Have the error message for missing recipients actually report the
missing config variable and not a fictional one.
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index cbbd02f..b188aa3 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -138,7 +138,15 @@ generate_email()
# Check if we've got anyone to send to
if [ -z "$recipients" ]; then
- echo >&2 "*** hooks.recipients is not set so no email will be sent"
+ case "$refname_type" in
+ "annotated tag")
+ config_name="hooks.announcelist"
+ ;;
+ *)
+ config_name="hooks.mailinglist"
+ ;;
+ esac
+ echo >&2 "*** $config_name is not set so no email will be sent"
echo >&2 "*** for $refname update $oldrev->$newrev"
exit 0
fi
^ permalink raw reply related
* [PATCH] add simple install replacement
From: Robert Schiele @ 2007-10-11 21:52 UTC (permalink / raw)
To: git; +Cc: gitster
This patch adds a very simple install replacement script to git.
This allows more easy installation on systems that don't have a
compatible install.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
---
gitinstall | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
create mode 100755 gitinstall
diff --git a/gitinstall b/gitinstall
new file mode 100755
index 0000000..8b346d6
--- /dev/null
+++ b/gitinstall
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+MKDIRMODE=0
+MODE=755
+while getopts 'dm:' FLAG; do
+ case "$FLAG" in
+ d) MKDIRMODE=1;;
+ m) MODE="$OPTARG";;
+ *) exit 1;;
+ esac
+done
+if test "$OPTIND" != 1; then
+ shift `expr $OPTIND - 1`
+fi
+if test $MKDIRMODE = 1; then
+ mkdir -p "$@"
+ chmod "$MODE" "$@"
+else
+ if test $# = 2 && ! test -d "$2"; then
+ rm -rf "$2"
+ cp "$1" "$2"
+ chmod "$MODE" "$2"
+ else
+ FILES=
+ while test $# != 1; do
+ FILES="$FILES $1"
+ shift
+ done
+ for i in $FILES; do
+ rm -rf "$1/"`basename "$i"`
+ cp "$i" "$1"
+ chmod "$MODE" "$1/"`basename "$i"`
+ done
+ fi
+fi
--
1.5.2.4
^ permalink raw reply related
* snapshot @ git.kernel.org
From: g00fi/goofy_ @ 2007-10-11 21:51 UTC (permalink / raw)
To: git
Hi there,
is it possible that the snapshot function on git.kernel.org is broken?
In every tree I tried, the downloaded file is only ~200 byte.
Or did I misunderstand the snapshot-link?
rgds,
G.Harasek
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Sam Vilain @ 2007-10-11 21:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: martin f krafft, git discussion list
In-Reply-To: <alpine.LFD.0.999.0710100808150.3838@woody.linux-foundation.org>
Linus Torvalds wrote:
> So git doesn't try to avoid conflicts per se: the merge strategies are
> fundamentally pretty simple (rename detection and the whole "recursive
> merge" thing may not be simple code, but the concepts are pretty
> straightforward), and they handle all the really *obvious* cases, but at
> the same time, I feel strongly that anything even half-way subtle should
> not be left to the SCM - the SCM should show it and make it really easy
> for the user to then fix it up.
This is true. However I think there are some obvious places for
improvement that does look at the file history, when the regular
algorithm fails;
1. do a --cherry-pick rev-list on just the file being merged and see if
all the changes on one side disappear, in which case just take the result.
2. see if the files were identical at some point, in which case use a
new merge base for that file based on the changes since that revision.
I actually thought #2 was already the way recursive worked!
Sam.
^ 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