* Re: [PATCH 2/3] Make has_commit non-static
From: Junio C Hamano @ 2009-01-26 20:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jake Goulding, git
In-Reply-To: <alpine.DEB.1.00.0901261637300.25749@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 26 Jan 2009, Jake Goulding wrote:
>
>> Moving has_commit from branch to a common location in preparation for
>> using it in tag. Renaming it to commit_has_any_in_commit_list to be more
>> unique.
>
> I feel like bike-shedding for a change, and I'd also like to prove that
> not all Germans like long names:
>
> is_ancestor_of_any()
>
> Hmm?
Is it ancestor or descendant? The latter makes the name longer, though
;-)
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Junio C Hamano @ 2009-01-26 20:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Johannes Schindelin, Keith Cascio, git
In-Reply-To: <76718490901261149xfedc415j8f5dab677b90d693@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Mon, Jan 26, 2009 at 1:48 PM, Jeff King <peff@peff.net> wrote:
>> But then you have that problem that the _user_ is stuck specifying "OK,
>> turn on fancy features." And I don't relish the thought of typing "git
>> diff -J" every time. :)
>
> Well, this issue seems to come up every so often, so the idea would be:
>
> - We're adding a mechanism for scripts to communicate that they need
> plumbing context
> - Start using it in your scripts when calling git if you rely on a
> stable interface
> - In the next major release, git may introduce changes to commands
> which are not clearly plumbing if you haven't adopted the mechanism
Where do all of these nonsense come from? We are not adding any mechanism
for scripts to say they need plumbing context. By calling plumbing they
are already asking for stable plumbing behaviour.
The scripts can, if they want to, use newer options updated versions of
the plumbing commands offer, by passing them when they want to.
And the trigger to do so is up to the scripts. They can get new options
from the end user, or they can peek into user's configuration variables
similar to the diff.primer mentioned earlier in the discussion.
One way could be a new option --screw-me-with=name that can be given to a
plumbing command and tells it pretend as if the command line options
specified by the configuration variable of the given name were given
(e.g. a script runs "git diff-files --screw-me-with=diff.primer").
The important point is that it has to be opt _IN_.
^ permalink raw reply
* git push --all not so all (was: Re: [ANNOUNCE] conntrack-tools 0.9.10 released)
From: Jan Engelhardt @ 2009-01-26 20:03 UTC (permalink / raw)
To: git; +Cc: Netfilter Developer Mailing List, pablo
In-Reply-To: <497E03E7.7030201@netfilter.org>
On Monday 2009-01-26 19:41, Pablo Neira Ayuso wrote:
>Jan Engelhardt wrote:
>> On Sunday 2009-01-25 22:05, Pablo Neira Ayuso wrote:
>>
>>> Hi!
>>>
>>> The netfilter project presents another development release of the
>>> conntrack-tools. As usual, this release includes important fixes,
>>> improvements and new features, mainly:
>>
>> The git tag for 0.9.10 seems to be missing.
>
>I forgot to add git push --tags to my release scripts, thanks for the
>notice.
I always wonder why `git push --all` does not push everything
(it should be true to its name, really) — such as tags o_O
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* git 1.6.1 on AIX 5.3
From: Perry Smith @ 2009-01-26 20:02 UTC (permalink / raw)
To: git
I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build and it
does not seem to be set up to do out of tree builds. If that is not
true, please let me know.
The install process wants to call install with a -d option. AIX has
two install programs but they are pretty old -- neither takes a -d
option.
Is there a GNU install program I can get? I've not been able to
locate one.
The curious thing is I installed git 1.5.6.4 on a similar AIX system a
few months ago and succeeded.
Last -- just so I know for future reference, is this list a 'text only
email' list?
Thank you for your help,
Perry
Ease Software, Inc. ( http://www.easesoftware.com )
Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Dill @ 2009-01-26 19:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <200901261631.18157.jnareb@gmail.com>
I was thinking of handling it like the Linux kernel documentation...?
On 1/26/09, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 26 Jan 2009, Peter Krefting wrote:
>> Jakub Narebski wrote:
>>
>> > With GUI translations we just use gettext conventions. I don't know
>> > any such convention for docs:
>>
>> There is a lot of documentation being translated using PO files. po4a -
>> http://po4a.alioth.debian.org/ - is a nice starting point for that.
>
> I'm not sure if XLIFF wouldn't be better format to use to translate
> _documents_. Gettext was meant to translate, I think, not very long
> messages in programs.
>
> Also I am not sure how much support this idea has. True, in last Git
> User's Survey[1] 63% to 76% wanted (parts of) Documentation... but that
> was out of 325 people who answered this question, with 3236 responses
> to survey in total, so numbers are more like 6% - 8%.
>
> [1] http://git.or.cz/gitwiki/GitSurvey2008
> [2] http://translate.sourceforge.net/wiki/
>
> --
> Jakub Narebski
> Poland
>
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Junio C Hamano @ 2009-01-26 19:55 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901261318030.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I was just doing an annoying merge (I'd reorganized code while other
> people made changes to it), and I kept having the problem that it was hard
> to figure out what each side had done. Is there some way to ask git for
> the diffs between the common ancestor (which is unique in my case, so it's
> actually useful) and each of the sides of the merge?
Have you tried "git checkout --conflict=diff3 $that_conflicted_path"?
^ permalink raw reply
* Re: [PATCH] git-bundle(1): add no references required simplest case
From: Junio C Hamano @ 2009-01-26 19:53 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, gitster, spearce, git
In-Reply-To: <87d4e97uxb.fsf_-_@jidanni.org>
jidanni@jidanni.org writes:
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
> See http://article.gmane.org/gmane.comp.version-control.git/103576
> Documentation/git-bundle.txt | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
> index 1b66ab7..7c1e990 100644
> --- a/Documentation/git-bundle.txt
> +++ b/Documentation/git-bundle.txt
> @@ -164,6 +164,13 @@ $ git pull bundle
> would treat it as if it is talking with a remote side over the
> network.
>
> +If a bundle requires no references, one may simply use:
Two nits.
1. Bundle does not require reference;it requires commits.
2. "One may simply use:" with a recipe without saying what the recipe is
useful for is not very helpful.
The second point needs to be stressed. For example, you could say
something like this:
With any bundle, you may simply say:
$ git ls-remote bundle.bdl
and it is a correct description if it is to see the refs in the bundle is
what you want to do, but it does not help when cloning from it is what you
want.
It would be a good practice to make the new part go with the flow of the
existing examples. Adding the following at the end might be a better way
to do this than your "init then pull" example:
A complete bundle is one that does not require you to have any
prerequiste object for you to extract its contents. Not only you
can fetch/pull from a bundle, you can clone from a complete bundle
as if it is a remote repository, like this:
----------------
$ git clone /home/me/tmp/file.bdl mine.git
----------------
This will define a remote called "origin" in the resulting
repository that lets you fetch and pull from the bundle, just
like the previous example lets you do with the remote called
"bundle", and from then on you can fetch/pull to update the
resulting mine.git repository after replacing the bundle you store
at /home/me/tmp/file.bdl with incremental updates.
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Daniel Barkalow @ 2009-01-26 19:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0901261100200.5284@localhost.localdomain>
On Mon, 26 Jan 2009, Linus Torvalds wrote:
> On Mon, 26 Jan 2009, Daniel Barkalow wrote:
> >
> > I was just doing an annoying merge (I'd reorganized code while other
> > people made changes to it), and I kept having the problem that it was hard
> > to figure out what each side had done. Is there some way to ask git for
> > the diffs between the common ancestor (which is unique in my case, so it's
> > actually useful) and each of the sides of the merge? Ideally, it would
> > give essentially the converse of the --cc diff: first column is -stage 1
> > +stage 2; second column is -stage 1 +stage 3.
>
> Have you tried "gitk --merge [filename]"?
>
> That's usually even more useful - because it doesn't just give a diff, it
> gives the actual commits that caused the conflict. That way you see what
> both sides of a merge tried to do.. It's what I do when encountering
> conflicts on the kernel (where I'm usually not the author of _either_ side
> of the code that causes a conflict), and it really is very powerful.
That is really nice, and quite handy. I ended up getting approximately
that effect with blame and show, but gitk is much easier. For some reason,
I never think of the graphical tools. Is there an easy way of focusing on
the changes that end up in a particular conflict? Half of the work was
finding the right commit and finding the right part of the diff.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jay Soffian @ 2009-01-26 19:49 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Keith Cascio, Junio C Hamano, git
In-Reply-To: <20090126184829.GA27543@coredump.intra.peff.net>
On Mon, Jan 26, 2009 at 1:48 PM, Jeff King <peff@peff.net> wrote:
> But then you have that problem that the _user_ is stuck specifying "OK,
> turn on fancy features." And I don't relish the thought of typing "git
> diff -J" every time. :)
Well, this issue seems to come up every so often, so the idea would be:
- We're adding a mechanism for scripts to communicate that they need
plumbing context
- Start using it in your scripts when calling git if you rely on a
stable interface
- In the next major release, git may introduce changes to commands
which are not clearly plumbing if you haven't adopted the mechanism
Where mechanism could be a switch, environment variable, etc.
Typically in a network API, the client and server have a way to
negotiate the highest level each supports; that's missing from git,
but seems like it would be useful.
j.
p.s. perhaps you'd prefer -P? :)
^ permalink raw reply
* Re: [PATCH v2] Allow format-patch to create patches for merges
From: Sverre Rabbelier @ 2009-01-26 19:34 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <1232988212-8613-1-git-send-email-nathan.panike@gmail.com>
On Mon, Jan 26, 2009 at 17:43, Nathan W. Panike <nathan.panike@gmail.com> wrote:
> This seems to solve my problem, but maybe my workflow is sufficiently different
> that it is a problem no one else has. Maybe someone can point me in a direction
> that solves problems more users have.
It seems like you want to use bundles instead of patches? Since you're
using it just to propagate your changes...?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-26 19:29 UTC (permalink / raw)
To: git
Hi,
I'd like to create a branch in a subversion repository so that I can
work with git-svn on it.
My git repository is already with a history, that I don't want to
replicate to subversion, I want to start with subversion having just the
latest revision and then continue from there normally (git svn
dcommit/rebase).
How can I do that?
Thanks,
Ittay
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Sverre Rabbelier @ 2009-01-26 19:30 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jakub Narebski, Peter Krefting, Dill, Git Mailing List
In-Reply-To: <20090126162351.GA8911@glandium.org>
On Mon, Jan 26, 2009 at 17:23, Mike Hommey <mh@glandium.org> wrote:
> On the other hand, the people who would really need the translations
> didn't answer the survey at all, since they couldn't read it.
Perhaps the basics can be translated at least, the documents that do
not require much change because they represent stable concepts?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Using the "What's cooking" scripts outside of Git
From: R. Tyler Ballance @ 2009-01-26 19:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
I was toying around with the idea of generating a "What's cooking" email
similar to Junio's for our internal development, and I'm wondering if
anybody has any experience using the scripts outside of the standard Git
repository.
Our repo is laid out slightly different, there's no "next" branch but
there are a number of "in development" branches that get folded down
into master.
Any tips would be appreciated
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] Make has_commit non-static
From: Jake Goulding @ 2009-01-26 19:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901261637300.25749@intel-tinevez-2-302>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 26 Jan 2009, Jake Goulding wrote:
>
>> Moving has_commit from branch to a common location in preparation for
>> using it in tag. Renaming it to commit_has_any_in_commit_list to be more
>> unique.
>
> I feel like bike-shedding for a change, and I'd also like to prove that
> not all Germans like long names:
>
> is_ancestor_of_any()
>
> Hmm?
I assume that this means that the rest of the code/logic is fine? :-D
I'll change this (I don't have any attachment to one name or the other),
then it should be good to go!
-Jake
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Bruce Stephens @ 2009-01-26 19:11 UTC (permalink / raw)
To: Peter Simons; +Cc: git
In-Reply-To: <87mydet0yg.fsf@write-only.cryp.to>
Peter Simons <simons@cryp.to> writes:
[...]
> The buffer is in "log-edit" mode.
Ah, OK. That makes sense.
> > In that case you could stick this in your .emacs if you wanted to
> > use message-mode:
> >
> > (setq auto-mode-alist (cons '("COMMIT_EDITMSG" . message-mode) auto-mode-alist))
>
> Unfortunately, it's not that easy.
True. I don't use git-mode (well, not much). I use git commit from
the command line, which runs emacsclient as its editor.
> I'm not an Emacs expert, but I'd assume that switching into a
> different mode would change the meaning of C-c C-c.
Yep. Quite likely other things, too.
OK, something like this:
(add-hook 'log-edit-mode-hook (lambda ()
(let ((regexp "--text follows this line--$\\|[ ]*$\\|-- $\\|---+$\\|^\f$\\|.*wrote:$\\|\\(\\([ ]*[-_.[:word:]]+>+\\|[ ]*[]>|}+]\\)+\\)[ ]*$\\|<#!*/?\\(multipart\\|part\\|external\\|mml\\|secure\\)"))
(setq paragraph-start regexp
paragraph-separate regexp)))
I copied the regexp from the value in message-mode. (In a junk buffer
use M-x message-mode, then C-h v paragraph-start and copy & paste.)
I imagine large parts of the regexp aren't relevant for your purposes
so you could remove them if you wanted. You might also define a
function rather than using lambda---that would make it a bit easier to
test.
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Daniel Barkalow @ 2009-01-26 19:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901261958320.25749@intel-tinevez-2-302>
On Mon, 26 Jan 2009, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 26 Jan 2009, Daniel Barkalow wrote:
>
> > I was just doing an annoying merge (I'd reorganized code while other
> > people made changes to it), and I kept having the problem that it was hard
> > to figure out what each side had done. Is there some way to ask git for
> > the diffs between the common ancestor (which is unique in my case, so it's
> > actually useful) and each of the sides of the merge?
>
> How about
>
> git diff HEAD...MERGE_HEAD
>
> and
>
> git diff MERGE_HEAD...HEAD
>
> ? I might have misunderstood, though.
That's definitely helpful information (and I'd forgotten about it; I was
only thinking of the index). It would be helpful to get it in --cc form,
though, rather than as two independant diffs. And it seems somewhat
wasteful or something to not use the information in the index, although
it's hard to get worked up about with git being blindingly fast anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Common ancestor in merge diffs?
From: Linus Torvalds @ 2009-01-26 19:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901261318030.19665@iabervon.org>
On Mon, 26 Jan 2009, Daniel Barkalow wrote:
>
> I was just doing an annoying merge (I'd reorganized code while other
> people made changes to it), and I kept having the problem that it was hard
> to figure out what each side had done. Is there some way to ask git for
> the diffs between the common ancestor (which is unique in my case, so it's
> actually useful) and each of the sides of the merge? Ideally, it would
> give essentially the converse of the --cc diff: first column is -stage 1
> +stage 2; second column is -stage 1 +stage 3.
Have you tried "gitk --merge [filename]"?
That's usually even more useful - because it doesn't just give a diff, it
gives the actual commits that caused the conflict. That way you see what
both sides of a merge tried to do.. It's what I do when encountering
conflicts on the kernel (where I'm usually not the author of _either_ side
of the code that causes a conflict), and it really is very powerful.
That said, finding the diffs from the common case is pretty trivial too.
Just do
git diff MERGE_HEAD...HEAD [filename]
and you'll get the diff from the common case to the HEAD, and if you
switch them around, you'll get the diff from the common commit to the
MERGE_HEAD. Note the _three_ dots.
Linus
^ permalink raw reply
* [PATCH] make: Remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 19:03 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
In-Reply-To: <497E079C.7090303@tedpavlic.com>
As discussed in
http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
the Mac OS X C standard library is always thread safe and always
includes the pthread library. So explicitly using -pthread causes an
'unrecognized option' compiler warning.
This patch clears PTHREAD_LIBS if Darwin is detected.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
Rather than simply clearing PTHREAD_LIBS, would it be better to filter
PTHREAD_LIBS to remove "-pthread" if detected?
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..9d451cf 100644
--- a/Makefile
+++ b/Makefile
@@ -817,6 +817,7 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+ PTHREAD_LIBS =
endif
ifndef CC_LD_DYNPATH
--
1.6.1.213.g28da8
^ permalink raw reply related
* [PATCH] git-bundle(1): add no references required simplest case
From: jidanni @ 2009-01-26 19:02 UTC (permalink / raw)
To: mdl123, gitster; +Cc: spearce, git
In-Reply-To: <87zlirc49l.fsf@jidanni.org>
Signed-off-by: jidanni <jidanni@jidanni.org>
---
See http://article.gmane.org/gmane.comp.version-control.git/103576
Documentation/git-bundle.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..7c1e990 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -164,6 +164,13 @@ $ git pull bundle
would treat it as if it is talking with a remote side over the
network.
+If a bundle requires no references, one may simply use:
+
+------------
+$ git init
+$ git pull bundle.bdl master
+------------
+
Author
------
Written by Mark Levedahl <mdl123@verizon.net>
--
1.6.0.6
^ permalink raw reply related
* Re: Common ancestor in merge diffs?
From: Johannes Schindelin @ 2009-01-26 18:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901261318030.19665@iabervon.org>
Hi,
On Mon, 26 Jan 2009, Daniel Barkalow wrote:
> I was just doing an annoying merge (I'd reorganized code while other
> people made changes to it), and I kept having the problem that it was hard
> to figure out what each side had done. Is there some way to ask git for
> the diffs between the common ancestor (which is unique in my case, so it's
> actually useful) and each of the sides of the merge?
How about
git diff HEAD...MERGE_HEAD
and
git diff MERGE_HEAD...HEAD
? I might have misunderstood, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH (update)] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr62q6jtp.fsf@gitster.siamese.dyndns.org>
...
>> This patch clears PTHREAD_LIBS by default. However, if
>> FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
>> before.
>
> Why is this even configurable? You explained pretty clearly that:
...
> But the above leaves the reader wondering in what situation it may be
> useful to use FORCE_* and for what purpose other than to get the nasty
> warning back (which probably is not most users want to).
I was afraid that there would be some strange situation where someone
would have a configuration where they might want pthreads turned on. I
suppose that if someone is in that specialized situation, they will be
able to customize their build environment on their own.
I will submit a new patch without the define.
Thanks --
Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-26 18:48 UTC (permalink / raw)
To: Jay Soffian; +Cc: Johannes Schindelin, Keith Cascio, Junio C Hamano, git
In-Reply-To: <76718490901260729m21ba140dke157d1d461aed2d5@mail.gmail.com>
On Mon, Jan 26, 2009 at 10:29:17AM -0500, Jay Soffian wrote:
> Aside, AIX has commands that are run both directly or via smit (a
> curses-based interface). When smit calls the commands, it passes a
> switch to let said commands know that they are being run from smit.
> e.g.:
>
> -J
> This flag is used when the installp command is executed from the
> System Management Interface Tool (SMIT) menus.
>
> Perhaps adding such a concept to those git commands which can be used
> in both porcelain and plumbing contexts would be useful for git.
Sure, I think that is one of many possible ways that we could
differentiate between confusing plumbing and porcelain; another is
splitting functionality into two similar commands, one of which is
plumbing and one of which is porcelain.
The real problem with plans like that, though, is that there are
_already_ scripts in the wild that don't understand "-J" (or whatever).
My impression from your description above is that "-J" means "don't use
fancy features, because we're being called from the menus". And you
really want the opposite, which is that scripts opt _in_ to fancy
features, not _out_.
But then you have that problem that the _user_ is stuck specifying "OK,
turn on fancy features." And I don't relish the thought of typing "git
diff -J" every time. :)
-Peff
^ permalink raw reply
* Common ancestor in merge diffs?
From: Daniel Barkalow @ 2009-01-26 18:41 UTC (permalink / raw)
To: git
I was just doing an annoying merge (I'd reorganized code while other
people made changes to it), and I kept having the problem that it was hard
to figure out what each side had done. Is there some way to ask git for
the diffs between the common ancestor (which is unique in my case, so it's
actually useful) and each of the sides of the merge? Ideally, it would
give essentially the converse of the --cc diff: first column is -stage 1
+stage 2; second column is -stage 1 +stage 3.
I think this would generally be more useful than the current diff output
for the unresolved portions (-stage 3 +working tree, -stage 2 +working
tree) because you're generally quite familiar with the working tree (since
you're trying to resolve there), and stage 1 is not obvious.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Johannes Gilger @ 2009-01-26 18:35 UTC (permalink / raw)
To: git
In-Reply-To: <c115fd3c0901260827ge5e4b29w871b345da2373f6b@mail.gmail.com>
On 2009-01-26, Tim Visher <tim.visher@gmail.com> wrote:
> easiest way to do this, short of installing cygwin, would be to do a
I know you said "short of installing cygwin", but I'd like to ask you if
you have ever used CygWin. I'd suggest you give it a try first (if you
haven't already) because it would then enable you to use a wide range of
tools from the unix-world without a lot of hassle. git, for example, can
be downloaded and compiled out-of-the-box, meaning the git-daemon as
well. You even get an ssh-server with cygwin (on windows, how cool is
that ;).
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: [PATCH] Allow format-patch to create patches for merges
From: Junio C Hamano @ 2009-01-26 18:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nathan W. Panike, git, aspotashev
In-Reply-To: <alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302>
[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> - lack an explanation when this makes sense (format-patch is commonly used
> for mail-based patch queues, and only -m 1 would make sense there, and
> only if you run format-patch with --first-parent),
You do not necessarily want --first-parent.
Suppose you have this topology
B---D---E
/ /
M---A---C
where M is 'master', and E is 'mine'.
The format-patch command ignores merges by default because you can get
diff for A-M, B-A, C-A, E-D and serialize the resulting history without
it, and this is often sufficient. When D merges with a conflict, or D is
an evil merge, however, you will not be able to reproduce how D looked
like on the receiving end. Your --first-parent would instead format the
log message for A B D E with patch text of A-M, B-A, D-B and E-D.
But as a recipient of such a patch series, I'd much prefer to see the
patch text and the log message of B and C themselves. I'd either apply
them on top of A serially, or apply them on top of A to recreate the
forked history the sender had and merge, to arrive at the state the sender
had at D either way, resolving a potential conflict (either when applying
C on top of B, or when merging between B and C), and apply E on top.
Getting a first parent diff that says "I merged random stuff here at D and
here is the difference D-B", is much less useful and throws us back to
dark ages of CVS/SVN merges, especially because C could be a long
multi-patch sequence.
I am not happy about Nathan's output. I think "-m" output is a wrong
thing to use in that it just lets D-B and D-C patches in the same output
file, without marking that it is something you should not be applying as
part of the series blindly. The patch is "If you reproduced my B and C
with the patches so far, here is a hint to help you recreate the merged
state D", and care must be taken to make sure both the tool and the user
notice the situation. "git am", after you have applied B and then C, will
notice that the patches for D does not apply anyway, but the message
should tell the recipient that it is _expected_ not to apply to avoid
confusion. One possible solution might be to always show --cc patch in
such a case, which (1) won't apply with patch nor git-am, and (2) will be
clear it is not a patch by having more than two @@ signs on each hunk
header.
If you really want to generate a patch for a merge commit (e.g. D in the
above picture), what you may want is "here is a fix-up you need to apply
on top of the result of naturally merging B and C to arrive at D". It
could be empty if the merge is conflict-free and there is no evil amend.
Here is a food-for-thought sample history for interested parties to
experiment on.
[-- Attachment #2: a bundle out of a sample repo --]
[-- Type: application/octet-stream, Size: 2036 bytes --]
^ 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