* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 16:04 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46B4A2B0.9080208@gmail.com>
Hi,
On Sat, 4 Aug 2007, Mark Levedahl wrote:
> git>git bisect good
Could you please
GIT_TRACE=1 make quick-install-doc
? It breaks here, too, but because I have no origin/man branch.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Johannes Schindelin @ 2007-08-04 16:08 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <46B4A35E.5040601@midwinter.com>
Hi,
On Sun, 5 Aug 2007, Steven Grimm wrote:
> David Kastrup wrote:
> > A system such as info, in contrast, is hierarchical, and organized
> > with indexes and cross references making it much easier to find
> > things.
>
> Really? I find info a huge pain in the butt most of the time. I can't just do
> a simple text search for the information I want in the relevant manpage;
I see the same.
> Am I alone in my dislike of info, I wonder?
There are so many reasons not to switch to info, but what you illustrated
is a very good one of those.
But yes, if you have the time, and it would be fun for you (before your
battery runs flat), I'd appreciate a small script to do a
quick-and-not-so-dirty conversion. Heck, if you use some kind of object
orientation, I might be talked into providing the html backend.
Ciao,
Dscho
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Mark Levedahl @ 2007-08-04 16:08 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
In-Reply-To: <46B4A2B0.9080208@gmail.com>
Mark Levedahl wrote:
> Johannes Schindelin wrote:
>> Could it be that you did not find this commit by bisecting the
>> issue? I highly doubt that said commit changes anything in the build
>> process.
>>
> git>git bisect good
> 6490a3383f1d0d96c122069e510ef1af1d019fbb is first bad commit
> commit 6490a3383f1d0d96c122069e510ef1af1d019fbb
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Thu Aug 2 15:10:56 2007 -0700
>
> Fix work-tree related breakages
Sorry - I hit send too fast on the previous mail. The relevant build
lines are:
GIT_INDEX_FILE=`pwd`/.quick-doc.index
export GIT_INDEX_FILE
rm -f "$GIT_INDEX_FILE"
git read-tree $head
git checkout-index -a -f --prefix="$mandir"/
After this commit, git checkout-index does not write the man files into
$mandir, before this commit, it does.
Mark Levedahl
^ permalink raw reply
* Re: [PATCH] git-clone: use cpio's --quiet flag
From: Jeff King @ 2007-08-04 16:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708041636290.14781@racer.site>
On Sat, Aug 04, 2007 at 04:36:59PM +0100, Johannes Schindelin wrote:
> > $ git-clone foo bar
> > Initialized empty Git repository in ...
> > 0 blocks
>
> According to http://www.opengroup.org/onlinepubs/7990989775/xcu/cpio.html,
> cpio does not know about --quiet. I think this is another GNUism...
Ugh, I didn't even think to check the spec, thanks for looking (I should
have been tipped off by the presence only of a long option).
I'm not sure what the best solution is...adding --quiet makes it totally
unportable, but that message almost looks like an error. We can redirect
stderr, but then we potentially miss real errors. I guess we could grep
it out.
-Peff
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Eran Tromer @ 2007-08-04 16:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, Sven Verdoolaege, git
In-Reply-To: <7v643vj316.fsf@assigned-by-dhcp.cox.net>
On 2007-08-04 01:13, Junio C Hamano wrote:
> Let me understand the problem first. If your first checkout
> does not check out the submodule, switching between revisions
> that has different commit of the submodule there would not fail,
> but once you checkout the submodule, switching without updating
> the submodule would be Ok (because by design updating the
> submodule is optional) but then further switching out of that
> state will fail because submodule in the supermodule tree and
> checked-out submodule repository are now out of sync. Is that
> the problem?
>
[snip]
> Where does the "No you are not up-to-date, I wouldn't let you
> switch" come from? Is that verify_uptodate() called from
> merged_entry() called from twoway_merge()? I think the right
> approach to deal with this is to teach verify_uptodate() about
> the policy. The function is about "make sure the filesystem
> entity that corresponds to this cache entry is up to date, lest
> we lose the local modifications". As we explicitly allow
> submodule checkout to drift from the supermodule index entry,
> the check should say "Ok, for submodules, not matching is the
> norm" for now. Later when we have the ability to mark "I care
> about this submodule to be always in sync with the superproject"
> (thereby implementing automatic recursive checkout and perhaps
> diff, among other things), we should check if the submodule in
> question is marked as such and perform the current test.
>
> How about doing something like this instead?
>
> unpack-trees.c | 9 +++++++++
Works here: it silences the check and allows switching branches. Still,
leaving the working tree dirty can inadvertently affect subsequent
commits. Consider the most ordinary of sequences:
$ git checkout experimental-death-ray
$ git submodules update
(return a week later, woozy from the vacation.)
$ git checkout master
(hack hack hack)
$ git commit -a -m "fixed typos"
$ git push
(Oops. You've just accidentally committed the wrong submodule heads.)
So to safely make new commits you must remember to always run "git
submodule update", or forgo use of "git commit -a", whenever submodules
might be involved.
I guess you can hack around this by excluding submodules from "commit
-a" and (for scripts) "ls-files -m" too...
Another approach is for pull, checkout etc. to automatically update the
submodule' head ref, but no more. In this case the supermodule always
sees a consistent state with traditional semantics, but the *submodule*
ends up with a dirty working tree and a head referring to a
possibly-missing commit; "git submodule update" would need to clean that up.
Eran
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Steven Grimm @ 2007-08-04 16:03 UTC (permalink / raw)
To: David Kastrup; +Cc: Sam Ravnborg, Junio C Hamano, Ismail Dönmez, git
In-Reply-To: <85zm17h4pn.fsf@lola.goethe.zz>
David Kastrup wrote:
> A system such as info, in contrast, is hierarchical, and organized
> with indexes and cross references making it much easier to find
> things.
Really? I find info a huge pain in the butt most of the time. I can't
just do a simple text search for the information I want in the relevant
manpage; I have to go navigating around to the appropriate subsection
(and that's assuming I know where it is) and am forced to use the
emacs-style pager whether I like it or not (not a big emacs fan here).
It always ticks me off when I go to read the manpage for some command
and it tells me to go read the info page if I want complete documentation.
I would definitely not want to move to a documentation system that
prevented me from typing "man git-commit" to get a list of all the
command line options for that command.
However, that said, I have no objection to an alternate view of the same
information that's organized differently.
Am I alone in my dislike of info, I wonder?
-Steve
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Mark Levedahl @ 2007-08-04 16:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708041637450.14781@racer.site>
Johannes Schindelin wrote:
> Could it be that you did not find this commit by bisecting the issue? I
> highly doubt that said commit changes anything in the build process.
>
> Ciao,
> Dscho
>
>
<snip ...>
git>git bisect good
6490a3383f1d0d96c122069e510ef1af1d019fbb is first bad commit
commit 6490a3383f1d0d96c122069e510ef1af1d019fbb
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Aug 2 15:10:56 2007 -0700
Fix work-tree related breakages
In set_work_tree(), variable rel needs to be reinitialized to
NULL on every call (it should not be static).
Make sure the incoming dir variable is not too long before
copying to the temporary buffer, and make sure chdir to the
resulting directory succeeds.
This was spotted and fixed by Alex and Johannes in a handful
patch exchanges. Here is the final version.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
:100644 100644 3653092ab657942639b6183fb04b3af783b77e7a
4945eb3134c3e047f54e51db25cd0aa81d9c47d7 M setup.c
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Lars Hjemli @ 2007-08-04 15:48 UTC (permalink / raw)
To: David Kastrup; +Cc: Jeff King, git
In-Reply-To: <85odhnfiau.fsf@lola.goethe.zz>
On 8/4/07, David Kastrup <dak@gnu.org> wrote:
> This whole "remote tracking" appears to be more a matter of _policy_
> rather than inherent design.
Absolutely.
> It would appear that local and remote
> tracking branches have no fundamental differences
I'd say they have no differences at all, it's just that
'git-checkout.sh' will refuse to update HEAD to point at something
outside of refs/heads.
--
larsh
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 15:38 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46B49617.3070402@gmail.com>
Hi,
On Sat, 4 Aug 2007, Mark Levedahl wrote:
> Beginning with commit
>
> 6490a3383f1d0d96c122069e510ef1af1d019fbb Fix work-tree related breakages
>
> install-doc-quick.sh no longer installs man pages, at least not to the defined
> $mandir (if "git-checkout-index" is putting them somewhere else, I haven't
> discovered where). Reverting the above commit eliminates this problem. This is
> on Cygwin, haven't tried on Linux.
Could it be that you did not find this commit by bisecting the issue? I
highly doubt that said commit changes anything in the build process.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-clone: use cpio's --quiet flag
From: Johannes Schindelin @ 2007-08-04 15:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070804070308.GA6493@coredump.intra.peff.net>
Hi,
On Sat, 4 Aug 2007, Jeff King wrote:
> Without this flag, cpio prints the number of blocks copied,
> leading to the somewhat confusing git-clone output:
>
> $ git-clone foo bar
> Initialized empty Git repository in ...
> 0 blocks
According to http://www.opengroup.org/onlinepubs/7990989775/xcu/cpio.html,
cpio does not know about --quiet. I think this is another GNUism...
Ciao,
Dscho
^ permalink raw reply
* Re: Some ideas for StGIT
From: Johannes Schindelin @ 2007-08-04 15:22 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: git
In-Reply-To: <20070804141438.GA15821@pe.Belkin>
Hi,
On Sat, 4 Aug 2007, Chris Shoemaker wrote:
> IMO, here are some things that would probably be easier with an external
> patch stack:
>
> - directly editing the diff hunks
> - moving single diff hunks between patches
>
> Maybe there are others, too, but these are things I just don't do
> nearly as frequently as the things that git-rebase -i is good at. (I
> use git-rebase -i *constantly*).
Good to hear! (I almost missed this mail, since I usually skip the StGit
mails.)
> > The "cd ..", "quilt push -a" and off I am. That
> > the "database" of quilt is in a known format and I can hack on
> > it with an editor is a plus for me :-)
> > [end of quote]
>
> That sounds more like an argument from familiarity than anything else.
> Nobody (reasonable) directly hacks git's internal binary format. The
> "known format" I can hack with my editor is just the content itself.
> Honestly, when you have commit-handling that is as good as git's,
> there's really very little appeal left to editing the diffs directly.
Of course, you _could_ just export the patches as one mbox, edit them, and
reapply them:
git format-patch --stdout HEAD~4 > mbox.txt
$EDITOR mbox.txt # even moving hunks
git reset --hard HEAD~4
git am mbox.txt
If the need is great enough, it should be easy to hack something like this
into git rebase -i.
Ciao,
Dscho
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 15:22 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20070804104851.162d7e00.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> On Sat, 04 Aug 2007 16:01:55 +0200
> David Kastrup <dak@gnu.org> wrote:
>
>> So --track does not set up a tracking branch, but makes a local
>> _following_ branch _refer_ to a tracking branch.
>
> Sure, that's one way to describe it; perhaps it would be best if
> we switched to that nomenclature in the documentation.
Not according to my current understanding, but that can, of course,
change again in the next few hours. As far as I understand right now,
such a branch indeed tracks a remote branch (and not a remote tracking
branch), it just does not track it recklessly: it has a head of its
own, and it won't use git-fetch -f for updating it.
> It's not a problem, you could just add an appropriate [branch...] section
> in your .git/config. Actually looking at a typical branch section
> is even more confusing to me:
>
> $ git branch fudge origin/fix1
>
> adds this to the .git/config:
>
> [branch "fudge"]
> remote = origin
> merge = refs/heads/fix1
>
> The config file does not record the remote-tracking-branch, instead
> it explicitly records the remote repository information. So it sure
> appears that if you add the --track option, it _does_ make the local
> branch track a remote directly. Thus it's hard to call it anything
> but what you labelled it, a local tracking-branch.
Yes, it seems --track does track after all. Just more cautiously than
a remote tracking branch does.
> While I thought i had a handle on this, i'm now officially more
> confused than you;
Good. It means that I may not be a complete idiot. It may also mean
that the documentation can be improved in places. With a lot of
"grep" and fine-combing I realized that quite a bit of the information
_is_ "available" (and some conflicting information as well).
This is one reason why I would prefer to have something like a typical
Texinfo manual, at least on the organisational level: a manual is
supposed to present a single connected view to the available
documentation. And the information for git is scattered through a
bunch of mostly disconnected files.
If you want to see a more staggering example of this approach, take a
look at the "guilt" documentation. It consists only of the man pages
for the individual commands, and then some few README-like files which
mostly say something like "guilt is just like quilt, or like
Mercurial's patch sets". That's rather extreme as far as
user-accessible information goes. git has a few more generally useful
files explaining underlying concepts, but they still are basically
thrown into one large self-service heap, not a coherent document.
> hopefully someone with knowledge of the guts of Git will speak up.
I think I am slowly getting it, thanks to Lars and others.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Michael @ 2007-08-04 15:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Steven Grimm, Ismail Dönmez
In-Reply-To: <7vfy2zj4nj.fsf@assigned-by-dhcp.cox.net>
On Saturday 04 August 2007 06:38, Junio C Hamano wrote:
> It might be more worthwhile to research what other "Text-ish
> lightweight mark-up" systems are availble, and if there is one
> that is more efficient and can go to at least html and man,
> one-time convert our documentation source to that format using
> your Perl magic. The minimum requirements are:
>
> * The source is readable without too much mark-up distraction;
>
> * Can go to roff -man;
>
> * Can go to html.
I know about txt2tags, but I'm not sure it will be the right choice.
http://txt2tags.sourceforge.net/
It's in python, uses a markup similar to wiki, and can be used to
create documentation in man, html, plain txt.
But I haven't used it very much.
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 15:09 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jeff King, git
In-Reply-To: <8c5c35580708040735l54d1b9c7i40cd80d7d11e2961@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 8/4/07, David Kastrup <dak@gnu.org> wrote:
>> Can we get merge conflicts
>> with a remote tracking branch, too? Namely when the remote branch
>> messed with its history, rebased/reverted stuff?
>
> No, since the "fetch" line in .git/config is prefixed by '+', which
> gets translated to the '-f' option for 'git-fetch'.
>
> And this was probably the primary reason for refs/remotes/* in the
> first place: you have a namespace in which there is no chance for
> 'git-fetch' to overwrite local changes (ancient git had no such
> namespace).
Ok, so a remote tracking branch is a forcefully merged branch, so we
put it into a separate category where we won't get tempted to have a
branch head which will get overwritten.
This whole "remote tracking" appears to be more a matter of _policy_
rather than inherent design. It would appear that local and remote
tracking branches have no fundamental differences, they just get
different defaults which make it less likely for the first to lose
local changes, and less likely for the second to miss remote changes
(in particular where those involve messing up the history).
But it would be easy to create chimeras when working outside of the
porcelain, right?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* rc4 - make quick-install-doc is broken
From: Mark Levedahl @ 2007-08-04 15:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Beginning with commit
6490a3383f1d0d96c122069e510ef1af1d019fbb Fix work-tree related breakages
install-doc-quick.sh no longer installs man pages, at least not to the
defined $mandir (if "git-checkout-index" is putting them somewhere else,
I haven't discovered where). Reverting the above commit eliminates this
problem. This is on Cygwin, haven't tried on Linux.
Mark Levedahl
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Julian Phillips @ 2007-08-04 14:50 UTC (permalink / raw)
To: David Kastrup; +Cc: Lars Hjemli, Jeff King, git
In-Reply-To: <85y7grfkbe.fsf@lola.goethe.zz>
On Sat, 4 Aug 2007, David Kastrup wrote:
> David Kastrup <dak@gnu.org> writes:
>
>> "Lars Hjemli" <hjemli@gmail.com> writes:
>>
>>>>> Was this helpful?
>>>
>>> Talking to myself: obviously not
>>
>> Disagree. "Does this answer all questions and makes git's behavior
>> perfectly transparent" -- no. But let's not confuse "magical" with
>> "helpful" here.
>
> Ok, let's have another go. Maybe I have understood more as compared
> with last time.
>
> git-branch/git-commit -b creates and manages local branches, nothing
> else. Local branches' defining feature is that they have a branch
> head I can move around myself.
>
> Then there are non-local branches. Their defining feature is that
> they have no locally moving branch head and _must_ track a remote
> branch.
>
> But local branches _also_ can track the progress/head of a remote
> branch. Since they have a locally moving branch head, this will often
> lead to merge conflicts which must be resolved.
>
> So this is more or less what I understand now. There really is no
> difference between "tracking" and "following" as I thought previously.
> It is just that a local branch which happens to track a remote branch
> is basically a remote tracking branch with a head of its own.
>
> Which means it can get merge conflicts. Can we get merge conflicts
> with a remote tracking branch, too? Namely when the remote branch
> messed with its history, rebased/reverted stuff?
Well, sort of - they are not really merge conflicts as there is no merging
involved. Fetching is strictly an updating process, either we update the
branch or we don't.
When updating a remote tracking branch there are two possible scenarios:
1) the new head is a superset of the old head (i.e. the old head forms
part of the history of the new)
2) the new head is not a superset of the old head (i.e. the old head does
not form part of the history of the new)
The normal case is 1), and we simply update the branch to point at the
new commit. However what happens in case 2) depends on the configuration.
If we have told git to force an update (indicated by the '+' on the
beginning of the fetch line in the config) then we simply accept the new
head as with case 1), otherwise we complain to the user and don't update
that branch
> So that the real difference between a local and a remote tracking
> branch is not that the latter tracks a remote branch (the former can
> do that as well), but that the latter has no local branch head and
> that saves us a lot (but not necessary all) merge conflicts?
Yes. A remote tracking branch is basically a read-only local cache of
something that exists in some other repository.
--
Julian
---
If you're going to do something tonight that you'll be sorry for tomorrow
morning, sleep late.
-- Henny Youngman
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Sean @ 2007-08-04 14:48 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85ejijgzzg.fsf@lola.goethe.zz>
On Sat, 04 Aug 2007 16:01:55 +0200
David Kastrup <dak@gnu.org> wrote:
> So --track does not set up a tracking branch, but makes a local
> _following_ branch _refer_ to a tracking branch.
Sure, that's one way to describe it; perhaps it would be best if
we switched to that nomenclature in the documentation.
> What happens with
>
> git checkout origin/branchX
> git branch --track mylocalbranch
> git checkout mylocalbranch
This is easy to test, and the answer is that no tracking is set up.
You must supply the remote-tracking-branch on the command line with
the --track option to git branch. Actually I realized that with a
new enough version of Git, --track is implied.
> ? What if after the checkout (which leads to a detached head) I check
> in a few things, and then decide to name the branch and set it up as
> following a remote tracking branch? Instead of using git-branch for
> setting up the following, do I have to explicitly add the respective
> "remote" line (which does not specify a remote, but a remote tracking
> branch) into, uh, where?
It's not a problem, you could just add an appropriate [branch...] section
in your .git/config. Actually looking at a typical branch section
is even more confusing to me:
$ git branch fudge origin/fix1
adds this to the .git/config:
[branch "fudge"]
remote = origin
merge = refs/heads/fix1
The config file does not record the remote-tracking-branch, instead
it explicitly records the remote repository information. So it sure
appears that if you add the --track option, it _does_ make the local
branch track a remote directly. Thus it's hard to call it anything
but what you labelled it, a local tracking-branch.
While I thought i had a handle on this, i'm now officially more
confused than you; hopefully someone with knowledge of the guts
of Git will speak up. Junio Help!
Sean
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-04 14:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, git
In-Reply-To: <20070804062010.GQ20052@spearce.org>
On Sat, Aug 04, 2007 at 02:20:10AM -0400, Shawn O. Pearce wrote:
> But at this point in git (and git-gui's) life I think it would
> be very worthwhile to devote an entire (new) chapter to git-gui,
> maybe as part of git 1.5.4/git-gui 0.9.0. I think we're far too
> late in the 1.5.3 cycle to do it now. I personally won't have the
> time to even try to rough draft something anytime soon, let alone
> let others copy-edit me before Juino releases 1.5.3. :)
>
> Being bundled with core git has brought git-gui a sizeable and
> growing userbase, and more and more users are discovering it
> each day. We're now seeing it be translated into many different
> languages, and it is a somewhat core part of the MSYS port as many
> Windows users prefer to click in GUIs over type in cmd.exe terminal
> windows (can't say I blame them, cmd.exe is aweful!).
>
> In other words I think git-gui should get roughly as much attention
> from the user manual as git-add/rm/mv/commit/checkout/branch get,
> as it offers the same feature set. But it shouldn't distract from
> the command line part of the manual.
>
> Maybe we should write parts of the manual in a "choose your own
> adventure style" and use different chapters for different paths.
> I think users can easily decide between the command line "i like to
> type" vs. the gui "i like to click" paths and focus their attention
> to the material they are most interested in. :-)
Sure.
For now, though, I think it'd be simplest to start with an entirely
separate appendix. And find a way to make links to that chapter are
prominently featured in Windows ports, as that sounds like an immediate
need.
And then later as git-gui progresses we can figure out how to integrate
it better.
--b.
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Lars Hjemli @ 2007-08-04 14:35 UTC (permalink / raw)
To: David Kastrup; +Cc: Jeff King, git
In-Reply-To: <85y7grfkbe.fsf@lola.goethe.zz>
On 8/4/07, David Kastrup <dak@gnu.org> wrote:
> Can we get merge conflicts
> with a remote tracking branch, too? Namely when the remote branch
> messed with its history, rebased/reverted stuff?
No, since the "fetch" line in .git/config is prefixed by '+', which
gets translated to the '-f' option for 'git-fetch'.
And this was probably the primary reason for refs/remotes/* in the
first place: you have a namespace in which there is no chance for
'git-fetch' to overwrite local changes (ancient git had no such
namespace).
--
larsh
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: J. Bruce Fields @ 2007-08-04 14:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Junio C Hamano, Ismail Dönmez, git
In-Reply-To: <Pine.LNX.4.64.0708041235190.14781@racer.site>
On Sat, Aug 04, 2007 at 12:38:35PM +0100, Johannes Schindelin wrote:
> There have been a few suggestions to step away from asciidoc in this
> thread now. IMNSVHO the only switch which would actually make sense,
> would be towards the Wiki format.
>
> Why?
>
> Because right now, we have a _ton_ of documentation on the Gitwiki, and
> no easy way to import it back. We also have at least one document which
> is (semi-regularly) converted from ascii to Wiki markup.
Possibly I'm paranoid, but for the stuff we distribute in our source
tree I'd like to know who contributed, and to know that they were really
aware of the license. That may be an obstacle to mass import of
documentation from the wiki--I don't know.
Whether the wiki markup is a sensible markup language is a separate
question.
--b.
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 14:25 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jeff King, git
In-Reply-To: <854pjfgzit.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
>>> > Was this helpful?
>>
>> Talking to myself: obviously not
>
> Disagree. "Does this answer all questions and makes git's behavior
> perfectly transparent" -- no. But let's not confuse "magical" with
> "helpful" here.
Ok, let's have another go. Maybe I have understood more as compared
with last time.
git-branch/git-commit -b creates and manages local branches, nothing
else. Local branches' defining feature is that they have a branch
head I can move around myself.
Then there are non-local branches. Their defining feature is that
they have no locally moving branch head and _must_ track a remote
branch.
But local branches _also_ can track the progress/head of a remote
branch. Since they have a locally moving branch head, this will often
lead to merge conflicts which must be resolved.
So this is more or less what I understand now. There really is no
difference between "tracking" and "following" as I thought previously.
It is just that a local branch which happens to track a remote branch
is basically a remote tracking branch with a head of its own.
Which means it can get merge conflicts. Can we get merge conflicts
with a remote tracking branch, too? Namely when the remote branch
messed with its history, rebased/reverted stuff?
So that the real difference between a local and a remote tracking
branch is not that the latter tracks a remote branch (the former can
do that as well), but that the latter has no local branch head and
that saves us a lot (but not necessary all) merge conflicts?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] git-submodule: re-enable 'status' as the default subcommand
From: Lars Hjemli @ 2007-08-04 14:25 UTC (permalink / raw)
To: git
This was broken as part of ecda072380.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2cfeadd..3320998 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -313,7 +313,7 @@ case "$add,$init,$update,$status,$cached" in
,,1,,)
modules_update "$@"
;;
-,,,1,*)
+,,,*,*)
modules_list "$@"
;;
*)
--
1.5.3.rc4-dirty
^ permalink raw reply related
* Re: [MinGW PATCH] 'git clone git://...' was failing inside git-read-tree with 'fatal: Not a valid object name HEAD'
From: Johannes Schindelin @ 2007-08-04 14:16 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git, johannes.sixt
In-Reply-To: <F7C35F51E58245FDA1EE1C2F2B4EB204@ntdev.corp.microsoft.com>
Hi,
On Sat, 4 Aug 2007, Dmitry Kakurin wrote:
> NOTE: This fix uses is_absolute_path from msysGit-0.3.exe that is not in
> mingw.git yet.
Ooops. I think I did not even check that into msysgit.git. Thanks.
> - if (gitdirenv[0] != '/') {
> + if ( !is_absolute_path( gitdirenv ) ) {
Our coding style does not want them extra spaces...
+ if (!is_absolute_path(gitdirenv)) {
is the way we prefer it.
Ciao,
Dscho
^ permalink raw reply
* Re: Some ideas for StGIT
From: Chris Shoemaker @ 2007-08-04 14:14 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Andy Parkins, git, Catalin Marinas
In-Reply-To: <1186206085.28481.33.camel@dv>
On Sat, Aug 04, 2007 at 01:41:25AM -0400, Pavel Roskin wrote:
> Hello, Andy!
>
> On Fri, 2007-08-03 at 19:14 +0100, Andy Parkins wrote:
> > On Friday 2007, August 03, Pavel Roskin wrote:
> >
> > > I don't suggest that StGIT gives up on the git-based storage, but this
> > > mode of operation could be implemented in two ways.
> >
> > git's shiny new git rebase -i has removed, for me, those times when I needed
> > stgit. Perhaps those who've move from git to quilt would try again when
> > 1.5.3 is out with the magic that is "rebase -i".
>
> I don't understand how one option can replace StGIT. I assume you were
> trying to avoid StGIT already, and "git-rebase -i" was just the last
> missing piece.
FWIW, I'm in the same camp. I'm a huge fan of quilt, and used it
extensively and with large stacks. (Actually, I still use it whenever
I don't want to bother with importing-to-git a large CVS or SVN
project that I'm tracking.) When I started using git (and up until
the first time I used git-rebase -i), I assumed I'd eventually have to
use one of the quilt-like add-ons, but I wanted to hold off a little
while until I was comfortable with core-git.
But, after using git-rebase -i, I can't see why I'd need any
quilt-like add-on. Every time I use git-rebase -i, it's like I'm
editing the patch stack.
> It would be great if you could tell me how your approach would deal with
> the issue of editable patches I mentioned already. In case I was
> unclear, here's the quote from one of the developers:
>
> [quote]
> Sometimes, I just make patches in quilt, then I do "quilt
> refresh", "quilt pop -a", "cd patches" and modify the patches
> and series file manually, e.g. by moving one patch from one file
> into the other.
Well, there are many different ways one might want to modify the
stack, but I find that most of them are quite easy with git-rebase -i.
IMO, here are things that are easier with git-rebase -i than with an
external patch stack:
- editing the headers (git-rebase makes it easy to find/select the
patch and even opens the editor for me)
- reordering patches
- combining patches (squashing)
- moving one file's diff from one patch to another
IMO, here are some things that would probably be easier with an external
patch stack:
- directly editing the diff hunks
- moving single diff hunks between patches
Maybe there are others, too, but these are things I just don't do
nearly as frequently as the things that git-rebase -i is good at. (I
use git-rebase -i *constantly*).
> The "cd ..", "quilt push -a" and off I am. That
> the "database" of quilt is in a known format and I can hack on
> it with an editor is a plus for me :-)
> [end of quote]
That sounds more like an argument from familiarity than anything else.
Nobody (reasonable) directly hacks git's internal binary format. The
"known format" I can hack with my editor is just the content itself.
Honestly, when you have commit-handling that is as good as git's,
there's really very little appeal left to editing the diffs directly.
-chris
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 14:11 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jeff King, git
In-Reply-To: <8c5c35580708040703w44781498t7396588a3f8c81c8@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
>> > Was this helpful?
>
> Talking to myself: obviously not
Disagree. "Does this answer all questions and makes git's behavior
perfectly transparent" -- no. But let's not confuse "magical" with
"helpful" here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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