* Re: How to commit removed file?
From: Juergen Ruehle @ 2007-01-02 21:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael S. Tsirkin, git
In-Reply-To: <Pine.LNX.4.63.0701022211100.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin writes:
> On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:
>
> > > I'd like to remove a file and commit the removal while
> > > leaving out other changes in repository/index.
> > >
> > > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
> > > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
> > >
> > > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> > > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
> > > any file(s) known to git.
> > > Did you forget to 'git add'?
> > >
> > > A similiar thing works with "git add".
> >
> > Any ideas? Can this be done with git?
>
> Did you actually try the "--" thing I suggested in
> http://article.gmane.org/gmane.comp.version-control.git/35699/?
>
> Besides, I just tested with current "next":
>
> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
> 1 files changed, 0 insertions(+), 22 deletions(-)
> delete mode 100644 a234
But (at least in next from yesterday or something -- having an old
modem here only:-) it doesn't work if you delete the file using
git-rm, because git-commit -o operates only on known files: one of the
first things in this code path is a
git-ls-files --error-unmatch -- $@
This seems wrong because -o is supposed to bypass the index. It
should probably be doing ls-tree --name-only HEAD -- $@ instead, but
ls-tree doesn't have the --error-match functionality.
^ permalink raw reply
* Re: [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments
From: Jakub Narebski @ 2007-01-02 21:58 UTC (permalink / raw)
To: git
In-Reply-To: <052E1601-5422-48A0-81B3-9A454467CE5F@silverinsanity.com>
Brian Gernhardt wrote:
>> The reason is simple, I often use git commit as :wq in my editor,
>> and
>> sometimes think that in a A--B--C--D and in fact, I'd prefer to have:
>>
>> {A,C}--B--D. how is it possible to do that in a not too cumbersome
>> way? because that would make sens to work in some scratch branch, and
>> then reorganize patches in a saner better way in the master branch.
>>
>> But I fail to see how to achieve that without using cumbersome
>> export-to-patch then git apply patch and edit logs which is painful
>> and
>> not really using git.
>
> The command you seem to be looking for is git-cherry-pick. To
> combine the two commits, I'd do something like:
>
> $ git cherry-pick A
> $ git cherry-pick C
> $ git reset HEAD~2
> $ git add <files>
> $ git commit
Or better learn about --no-commit option of git-cherry-pick. Or if you
don't mind additional tools I think you can do this using StGIT.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Detached HEAD (experimental)
From: Carl Worth @ 2007-01-02 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac11yirf.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3942 bytes --]
On Mon, 01 Jan 2007 23:45:08 -0800, Junio C Hamano wrote:
> This allows "git checkout -d v1.4.3" to detach the HEAD from any
> branch but point directly at the named commit.
Being able to perform "checkout" with a tag like this, (and no
specific branch), is something I've been wanting git to acquire for
some time. So, thanks for coding this up!
> This is still experimental. While I think it makes sense to
> allow commits on top of detached HEAD, it is rather dangerous
> unless you are careful and know what you are doing.
This part I don't understand. I don't see why it's useful to introduce
new danger to "git checkout" in that after this change it could cause
commits to become dangling. Currently, "git checkout" is entirely
safe, as are most git commands. The few commands that create dangling
commits require fairly explicit actions from the user, (such as
"--hard" for git-reset or -D instead of -d for git-branch).
So I'd vote against this aspect. I'd rather see commits to a detached
head be disallowed with a message instructing the user to do "git
checkout -b new-branch" in order to do the commit.
And with that new safer behavior, I think it would be a good idea to
just drop the "-d" option from git-checkout.
I want this new behavior not for people who know what they are doing,
but people who are using git only incidentally, (say they just want to
acquire and build the latest version of some software). So I'd like
the sequence to work along the lines of your earlier post, (as quoted
by another reply). Specifically, I wouldn't want to see any warning
about a "missing branch" until a commit was attempted.
This would allow a sequence like this to proceed without git ever
telling the user they were doing something "wrong":
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git checkout v1.4.3
$ make
With the recent improvements to the git-checkout error message
(thanks!) this sequence is at least successful eventually after the
user reads and responds to the following:
git checkout: provided reference cannot be checked out directly
You need -b to associate a new branch with the wanted
checkout. Example:
git checkout -b <new_branch_name> v1.4.3
But the user is required to invent a name and deal with its existence
later. For example, after some time, imagine the same user wanting
to update to the latest and build again:
git pull origin
git checkout v1.5.0
Now the user has to invent _another_ unique branch name, (or learn
"git branch -d" or "git reset --hard" or ...), while this branch
concept and these other commands aren't actually helping the user with
the task at hand, (just tracking the code and building the most recent
version).
Similarly, I think this use case of "just tracking" should support
branches disappearing from the remote repository without the user
having to edit any config file. If there are entries that are
automatically added by git-clone that should be removed later, that
should happen automatically. A recent thread suggested adding an error
message instructing the user to delete the entries. That's again
unkind to a user who doesn't really want to learn git, but just wants
to get at the most recent version of some code that happens to be
available through git.
That disappearing branches cause problems requiring manual cleanup of
configuration files is one of the reasons that we are not using any
feature branches in the "central" cairo repository, for example, (we
do have branches for release maintenance). I'd really like to be able
to put some feature branches there for shared work, (rather than
forcing that work out to separate personal repositories as we do
know).
Maybe the configuration file entries added by git-clone need to be
marked in some way to distinguish them from manually added entries, so
that we would feel more comfortable automatically removing them when a
remote branch has disappeared.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments
From: Junio C Hamano @ 2007-01-02 22:01 UTC (permalink / raw)
To: Steve Frécinaux; +Cc: git
In-Reply-To: <20070102211339.GF17898@hades.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> ... and
> sometimes think that in a A--B--C--D and in fact, I'd prefer to have:
>
> {A,C}--B--D. how is it possible to do that in a not too cumbersome
> way? because that would make sens to work in some scratch branch, and
> then reorganize patches in a saner better way in the master branch.
>
> But I fail to see how to achieve that without using cumbersome
> export-to-patch then git apply patch and edit logs which is painful and
> not really using git.
First of all, "format-patch and then edit" is a perfectly sane
way to use git. Any workflow that takes advantage of cheap
branch creatin and cheap resetting of the tip of a branch _is_
"really using git". It depends on the size of the series you
are redoing, but I do that all the time.
Also cherry-pick, rebase, squash merge are your friends.
If you are on $original branch (which may be your 'master') with
commits A--B--C--D:
git checkout -b temp HEAD~3 ;# that's A
git cherry-pick $original~1 ;# that's C
git checkout $original
git rebase temp
would make the $original A--C'-B'-D'. Then:
git checkout temp ; git reset --hard $original~4 ;# parent of A
git merge -s squash $original~2 ;# squash A and C'
would prepare you to make a squashed commit out of the two to
the temp branch. Then:
git checkout $original
git rebase --onto temp HEAD~2 ;# that's C'
git branch -d temp
would give you (A+C)--B'-D' on $original branch.
StGIT would make life even easier for you. It is designed to
make things like the above simpler.
^ permalink raw reply
* Re: How to commit removed file?
From: Jakub Narebski @ 2007-01-02 22:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyatt8di.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:
>>
>>>> I'd like to remove a file and commit the removal while
>>>> leaving out other changes in repository/index.
>>>>
>>>> $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
>>>> rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
>>>>
>>>> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
>>>> error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did
not match
>>>> any file(s) known to git.
>>>> Did you forget to 'git add'?
>>>>
>>>> A similiar thing works with "git add".
>>>
>>> Any ideas? Can this be done with git?
>>
>> Did you actually try the "--" thing I suggested in
>> http://article.gmane.org/gmane.comp.version-control.git/35699/?
>>
>> Besides, I just tested with current "next":
>>
>> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
>> Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
>> 1 files changed, 0 insertions(+), 22 deletions(-)
>> delete mode 100644 a234
>
> The difference is Michael did "git rm" to explicitly tell git to
> forget about that path, while you used the vanilla "/bin/rm".
>
> Personally I never saw the point of having "git rm". Maybe we
> should remove it to prevent this confusion from happening.
Does this happen with new git-rm, which removes file also from
working directory?
BTW. you probably can do this with git-update-index...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Junio C Hamano @ 2007-01-02 22:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, git
In-Reply-To: <Pine.LNX.4.63.0701022219050.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> The reason we did the latter, by the way, does not have anything
>> to do with helping broken parsers. We drop the header after
>> re-coding the log message into an encoding specified by the user
>> (which is presumably different from what the commit was
>> originally recorded in) because the encoding recorded on
>> "encoding" header would not match the re-coded log message
>> anymore.
>
> By the same reasoning, you'd have to rewrite the committer line to reflect
> the current GIT_COMMITTER_IDENT, or hide it. If you want to convince me,
> you have to try harder.
Sorry, but you completely lost me with that analogy.
I think showing log message in the user's preferred encoding is
more like passing the output to the colorization mechanism and
then to the pager. We are interacting with humans at that
point, and we are changing the presentation without changing the
semantics of the data.
I do not see why committer identity needs to be rewritten nor
hidden by the same reasoning.
> And Marco has to fix the header parsing anyway.
No question about that. If iconv() punts, qgit will see
"encoding" header to deal with even when the re-coding is in
effect. I think it may be a sensible thing for qgit to replace
the log message and show "log message in this encoding, which
cannot be shown in this window" instead in such a case, but that
is up to Porcelain.
^ permalink raw reply
* Re: [PATCH] Detached HEAD (experimental)
From: Jakub Narebski @ 2007-01-02 22:18 UTC (permalink / raw)
To: git
In-Reply-To: <87ps9xgkjo.wl%cworth@cworth.org>
Carl Worth wrote:
> Similarly, I think this use case of "just tracking" should support
> branches disappearing from the remote repository without the user
> having to edit any config file. If there are entries that are
> automatically added by git-clone that should be removed later, that
> should happen automatically. A recent thread suggested adding an error
> message instructing the user to delete the entries. That's again
> unkind to a user who doesn't really want to learn git, but just wants
> to get at the most recent version of some code that happens to be
> available through git.
>
> That disappearing branches cause problems requiring manual cleanup of
> configuration files is one of the reasons that we are not using any
> feature branches in the "central" cairo repository, for example, (we
> do have branches for release maintenance). I'd really like to be able
> to put some feature branches there for shared work, (rather than
> forcing that work out to separate personal repositories as we do
> know).
>
> Maybe the configuration file entries added by git-clone need to be
> marked in some way to distinguish them from manually added entries, so
> that we would feel more comfortable automatically removing them when a
> remote branch has disappeared.
Is it still problem (the dissapearing remote branches) with the new
wildcard remote.<name>.fetch generated by new git-clone? I think it
should not complain that some branches vanished, but it would not I think
it would remove no longer needed tracking branches (local branches)
for us...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to commit removed file?
From: Johannes Schindelin @ 2007-01-02 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael S. Tsirkin
In-Reply-To: <7vfyatt8di.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 2 Jan 2007, Junio C Hamano wrote:
> The difference is Michael did "git rm" to explicitly tell git to forget
> about that path, while you used the vanilla "/bin/rm".
Ah. In this case, it is enough to just say "git commit"...
> Personally I never saw the point of having "git rm". Maybe we should
> remove it to prevent this confusion from happening.
People seem so used to "cvs remove" that they had to have "git rm". Dunno.
I never used it. (Except to verify that indeed even "--" does not work
with Michael's example.)
Ciao,
Dscho
^ permalink raw reply
* [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments
From: Pierre Habouzit @ 2007-01-02 22:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <enekbs$n8g$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]
On Tue, Jan 02, 2007 at 10:58:14PM +0100, Jakub Narebski wrote:
> Brian Gernhardt wrote:
>
> >> The reason is simple, I often use git commit as :wq in my editor,
> >> and
> >> sometimes think that in a A--B--C--D and in fact, I'd prefer to have:
> >>
> >> {A,C}--B--D. how is it possible to do that in a not too cumbersome
> >> way? because that would make sens to work in some scratch branch, and
> >> then reorganize patches in a saner better way in the master branch.
> >>
> >> But I fail to see how to achieve that without using cumbersome
> >> export-to-patch then git apply patch and edit logs which is painful
> >> and
> >> not really using git.
> >
> > The command you seem to be looking for is git-cherry-pick. To
> > combine the two commits, I'd do something like:
> >
> > $ git cherry-pick A
> > $ git cherry-pick C
> > $ git reset HEAD~2
> > $ git add <files>
> > $ git commit
>
> Or better learn about --no-commit option of git-cherry-pick. Or if you
> don't mind additional tools I think you can do this using StGIT.
oh those solutions look awsome and easily scriptable, which is
exactly what I need, and it feels simpler to use for my small brain than
the solution Junio proposed. thanks a lot !
I wonder why I never got to that alone ...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Johannes Schindelin @ 2007-01-02 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <7vps9xrs9y.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 2 Jan 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> The reason we did the latter, by the way, does not have anything
> >> to do with helping broken parsers. We drop the header after
> >> re-coding the log message into an encoding specified by the user
> >> (which is presumably different from what the commit was
> >> originally recorded in) because the encoding recorded on
> >> "encoding" header would not match the re-coded log message
> >> anymore.
> >
> > By the same reasoning, you'd have to rewrite the committer line to reflect
> > the current GIT_COMMITTER_IDENT, or hide it. If you want to convince me,
> > you have to try harder.
>
> Sorry, but you completely lost me with that analogy.
>
> I think showing log message in the user's preferred encoding is
> more like passing the output to the colorization mechanism and
> then to the pager. We are interacting with humans at that
> point, and we are changing the presentation without changing the
> semantics of the data.
>
> I do not see why committer identity needs to be rewritten nor
> hidden by the same reasoning.
>
> > And Marco has to fix the header parsing anyway.
>
> No question about that. If iconv() punts, qgit will see
> "encoding" header to deal with even when the re-coding is in
> effect. I think it may be a sensible thing for qgit to replace
> the log message and show "log message in this encoding, which
> cannot be shown in this window" instead in such a case, but that
> is up to Porcelain.
Ah! Now I get your reasoning. But it is wrong. You are misusing headers --
which should be metadata describing the commit -- to pass a vital
information to a porcelain: "re-encoding failed, please have a try
yourself".
But the encoding header describes a certain aspect of the commit object:
how it was _originally_ encoded.
It's just like mails: often I look at the X-Mailer: header to find out if
the sender by any chance used Windows, or Mac, because it may help me help
the sender when incomplete information was provided.
And just like with the mail, I would not like the tool to _hide_ the
headers from me when I ask for them, just because it happened to use them
already to display the characters correctly.
Ciao,
Dscho
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Marco Costalba @ 2007-01-02 22:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vps9xrs9y.fsf@assigned-by-dhcp.cox.net>
On 1/2/07, Junio C Hamano <junkio@cox.net> wrote:
>
> > And Marco has to fix the header parsing anyway.
>
> No question about that. If iconv() punts, qgit will see
> "encoding" header to deal with even when the re-coding is in
> effect. I think it may be a sensible thing for qgit to replace
> the log message and show "log message in this encoding, which
> cannot be shown in this window" instead in such a case, but that
> is up to Porcelain.
>
Yes, git-rev-list output is stored in memory as a big chunk of row
bytes, conversion
to utf8 (the internal format used by Qt string class) is done _only_
for displayed items, just
before to show them to user so is not performance critical. I agree
with Junio, that info could be used to teach Qt string conversion
function how to handle the data. Something like:
convertWithCodec(const char* data, codec* codecName)
So perhaps if Qt is better then iconv we could display a good log
message anyway.
^ permalink raw reply
* Re: [PATCH] Detached HEAD (experimental)
From: Junio C Hamano @ 2007-01-02 22:44 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87ps9xgkjo.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Mon, 01 Jan 2007 23:45:08 -0800, Junio C Hamano wrote:
>> This allows "git checkout -d v1.4.3" to detach the HEAD from any
>> branch but point directly at the named commit.
>
> Being able to perform "checkout" with a tag like this, (and no
> specific branch), is something I've been wanting git to acquire for
> some time. So, thanks for coding this up!
>
>> This is still experimental. While I think it makes sense to
>> allow commits on top of detached HEAD, it is rather dangerous
>> unless you are careful and know what you are doing.
>
> This part I don't understand. I don't see why it's useful to introduce
> new danger to "git checkout"...
I am not saying being risky is useful. That's why I said it is
experimental.
We could do two things, and I think disallowing commits is not
necessarily a better option of the two. We could allow commits
and prevent the user from switching out of the detached HEAD
state without an explicit action instead. If we go the first
route, you need to also prevent merges into the detached HEAD.
If we go the latter I think you only need to add a check in
"git-checkout" but there may be other cases. In either way, we
need a safety valve, which the experimental code does not have.
And being able to merge into the detached HEAD turns out to be
somewhat useful. I checked out the v1.4.4.3 and tried to see if
a topic is applicable by merging into that detached HEAD and
running testsuite. Of course, without any safety valve, I can
easily lose the merge result by switching out of the detached
HEAD state (say, "git checkout master"), but on the other hand,
creating a new branch at that point with "git checkout -b
v1.4.4.3-maint" would let me continue from that point without
losing anything.
But this is only "somewhat" -- I do not have strong opinion
either way, other than that we need a safety valve (which we
agree).
In any case, I did this because I got tired of waiting for it to
happen (I thought you wanted to hack on this over the long
week^W yearend, so I deliberately stayed away from doing this)
and I was bored. This will not be in 'next' in the current
shape.
You've thought about the issue long enough to write your
commentary and I agree to most of your points (including
favoring "no commit allowed in this state" over "allow commits
and merges to help advanced usage" for its simplicity), so if
you code it up with a clean patch, I would not reject it on the
basis of its design.
^ permalink raw reply
* Re: [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments
From: Steve Frécinaux @ 2007-01-02 23:09 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <20070102211339.GF17898@hades.madism.org>
Pierre Habouzit wrote:
> Though an operation that I'd often like to do is to merge two (or
> more) patches as one, and reedit its entry, preferably as a merge of the
> two (or more) old logs.
Actually that's more or less what I wanted to achieve, just that it was
less general.
Using the solutions that have been proposed in this thread (using
git-cherry-pick -n and a work branch) looks satisfying for what I want
to do. Then it's just a matter of cherry-picking the last "work"
patches, commiting them as a whole in master and then using git-svn
dcommit the regular way.
^ permalink raw reply
* Re: [PATCH] Detached HEAD (experimental)
From: Carl Worth @ 2007-01-02 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virfprquo.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
On Tue, 02 Jan 2007 14:44:31 -0800, Junio C Hamano wrote:
> We could do two things, and I think disallowing commits is not
> necessarily a better option of the two. We could allow commits
> and prevent the user from switching out of the detached HEAD
> state without an explicit action instead.
Yeah, that would be fine too. Personally, I'd be happy with either
approach.
> "git-checkout" but there may be other cases. In either way, we
> need a safety valve, which the experimental code does not have.
OK. I guess I misinterpreted things. I was afraid that you were
proposing a safety valve on _entering_ the detached state, (perhaps
the -d option to checkout itself). It was the requirement of something
extra to checkout a tag (as opposed to checkout of a branch) that I
disliked.
> In any case, I did this because I got tired of waiting for it to
> happen (I thought you wanted to hack on this over the long
> week^W yearend, so I deliberately stayed away from doing this)
> and I was bored. This will not be in 'next' in the current
> shape.
I'm glad you went ahead. I ended up almost not touching computers at
all from December 23 to January 2 [*].
> You've thought about the issue long enough to write your
> commentary and I agree to most of your points (including
> favoring "no commit allowed in this state" over "allow commits
> and merges to help advanced usage" for its simplicity), so if
> you code it up with a clean patch, I would not reject it on the
> basis of its design.
I don't actually prefer "no commit allowed". I just didn't want the
user to have to explicitly disable the safety before being able to
perform a checkout based on a tag.
I am still interested in this feature, so I will try to find time to
come back with a revised version of your patch with the missing safety
check (and without requiring -d on checkout). Thanks again for this
initial take on the problem. (Though if anyone else beats me to it, I
certainly will not be offended.)
-Carl
[*] I did play some nice new (to me) board games, (Zendo and DVONN
being standouts), but thats a topic for elsewhere I suppose.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Santi Béjar @ 2007-01-03 0:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <enef73$467$1@sea.gmane.org>
On 1/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
>
> > Obviously, the local names should matter more when you are doing
> > local operations. So if you are using mergeLocal to give a
> > shorthand to "git merge" that does not explicitly say what to
> > merge, the above discussion does not apply. But if that is the
> > case, mergeLocal should also not affect the selection of
> > branches to be merged when "git pull" happens from a remote
> > either.
>
> You can always use remote = ".", and then remote and local branches
> are the same...
Currently it does not work.
Santi
^ permalink raw reply
* Re: [PATCH] Detached HEAD (experimental)
From: Junio C Hamano @ 2007-01-03 2:45 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87odphgfzz.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> I don't actually prefer "no commit allowed". I just didn't want the
> user to have to explicitly disable the safety before being able to
> perform a checkout based on a tag.
Ok, then I think we are in agreement that the safety should be
at the point where the user might leave the detached state.
> I am still interested in this feature, so I will try to find time to
> come back with a revised version of your patch with the missing safety
> check (and without requiring -d on checkout). Thanks again for this
> initial take on the problem. (Though if anyone else beats me to it, I
> certainly will not be offended.)
Sounds good.
I do not mind losing -d, but I would suggest that there should
be a message that says "you are no longer on any branch" after a
checkout that makes the head detached. The user should be
warned about such an unusal situation.
^ permalink raw reply
* Re: [PATCH/RFC] Assorted small changes to runstatus
From: Junio C Hamano @ 2007-01-03 2:51 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: git
In-Reply-To: <1167765983316-git-send-email-j.ruehle@bmiag.de>
Thanks. 3 and 4 are obviously good, 1 is probably good although
I do not have much preference either way myself. The part that
adds helpful messages of 2 is nice but I am not sure about the
wording "Cached changes".
Maybe people who were in the update-index and git-add discussion
have better input than I can give.
^ permalink raw reply
* [PATCH] git-branch: show detached HEAD
From: Lars Hjemli @ 2007-01-02 23:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vac11yirf.fsf@assigned-by-dhcp.cox.net>
This makes git-branch show a detached HEAD as '* (no branch)'.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
This might be a premature patch. But if/when we allow HEAD to be detached,
git-branch should tell us that HEAD is the current 'branch'.
builtin-branch.c | 103 +++++++++++++++++++++++++++++-------------------------
1 files changed, 55 insertions(+), 48 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 71f88f2..16f86cc 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -231,29 +231,54 @@ static int ref_cmp(const void *r1, const void *r2)
return strcmp(c1->name, c2->name);
}
-static void print_ref_info(const unsigned char *sha1, int abbrev)
+static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
+ int abbrev, int current)
{
+ char c;
+ int color;
struct commit *commit;
char subject[256];
+ switch (item->kind) {
+ case REF_LOCAL_BRANCH:
+ color = COLOR_BRANCH_LOCAL;
+ break;
+ case REF_REMOTE_BRANCH:
+ color = COLOR_BRANCH_REMOTE;
+ break;
+ default:
+ color = COLOR_BRANCH_PLAIN;
+ break;
+ }
- commit = lookup_commit(sha1);
- if (commit && !parse_commit(commit))
- pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
- subject, sizeof(subject), 0,
- NULL, NULL, 0);
- else
- strcpy(subject, " **** invalid ref ****");
+ c = ' ';
+ if (current) {
+ c = '*';
+ color = COLOR_BRANCH_CURRENT;
+ }
- printf(" %s %s\n", find_unique_abbrev(sha1, abbrev), subject);
+ if (verbose) {
+ commit = lookup_commit(item->sha1);
+ if (commit && !parse_commit(commit))
+ pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
+ subject, sizeof(subject), 0,
+ NULL, NULL, 0);
+ else
+ strcpy(subject, " **** invalid ref ****");
+ printf("%c %s%-*s%s %s %s\n", c, branch_get_color(color),
+ maxwidth, item->name,
+ branch_get_color(COLOR_BRANCH_RESET),
+ find_unique_abbrev(item->sha1, abbrev), subject);
+ } else {
+ printf("%c %s%s%s\n", c, branch_get_color(color), item->name,
+ branch_get_color(COLOR_BRANCH_RESET));
+ }
}
-static void print_ref_list(int kinds, int verbose, int abbrev)
+static void print_ref_list(int kinds, int verbose, int abbrev, int detached)
{
int i;
- char c;
struct ref_list ref_list;
- int color;
memset(&ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
@@ -261,39 +286,22 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
- for (i = 0; i < ref_list.index; i++) {
- switch( ref_list.list[i].kind ) {
- case REF_LOCAL_BRANCH:
- color = COLOR_BRANCH_LOCAL;
- break;
- case REF_REMOTE_BRANCH:
- color = COLOR_BRANCH_REMOTE;
- break;
- default:
- color = COLOR_BRANCH_PLAIN;
- break;
- }
-
- c = ' ';
- if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
- !strcmp(ref_list.list[i].name, head)) {
- c = '*';
- color = COLOR_BRANCH_CURRENT;
- }
+ if (detached && (kinds & REF_LOCAL_BRANCH)) {
+ struct ref_item item;
+ item.name = "(no branch)";
+ item.kind = REF_LOCAL_BRANCH;
+ hashcpy(item.sha1, head_sha1);
+ if (strlen(item.name) > ref_list.maxwidth)
+ ref_list.maxwidth = strlen(item.name);
+ print_ref_item(&item, ref_list.maxwidth, verbose, abbrev, 1);
+ }
- if (verbose) {
- printf("%c %s%-*s%s", c,
- branch_get_color(color),
- ref_list.maxwidth,
- ref_list.list[i].name,
- branch_get_color(COLOR_BRANCH_RESET));
- print_ref_info(ref_list.list[i].sha1, abbrev);
- }
- else
- printf("%c %s%s%s\n", c,
- branch_get_color(color),
- ref_list.list[i].name,
- branch_get_color(COLOR_BRANCH_RESET));
+ for (i = 0; i < ref_list.index; i++) {
+ int current = !(detached && (kinds & REF_LOCAL_BRANCH)) &&
+ (ref_list.list[i].kind == REF_LOCAL_BRANCH) &&
+ !strcmp(ref_list.list[i].name, head);
+ print_ref_item(&ref_list.list[i], ref_list.maxwidth, verbose,
+ abbrev, current);
}
free_ref_list(&ref_list);
@@ -380,7 +388,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, force_delete = 0, force_create = 0;
int rename = 0, force_rename = 0;
- int verbose = 0, abbrev = DEFAULT_ABBREV;
+ int verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0;
int reflog = 0;
int kinds = REF_LOCAL_BRANCH;
int i;
@@ -458,8 +466,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (!head)
die("Failed to resolve HEAD as a valid ref.");
if (!strcmp(head, "HEAD")) {
- /* detached HEAD */
- ;
+ detached = 1;
}
else {
if (strncmp(head, "refs/heads/", 11))
@@ -470,7 +477,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc - i, argv + i, force_delete, kinds);
else if (i == argc)
- print_ref_list(kinds, verbose, abbrev);
+ print_ref_list(kinds, verbose, abbrev, detached);
else if (rename && (i == argc - 1))
rename_branch(head, argv[i], force_rename);
else if (rename && (i == argc - 2))
--
1.5.0.rc0.g76033
^ permalink raw reply related
* Re: [PATCH] git-branch: show detached HEAD
From: Shawn O. Pearce @ 2007-01-03 5:18 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano
In-Reply-To: <1167780131528-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> wrote:
> This makes git-branch show a detached HEAD as '* (no branch)'.
It would be nicer if when you are on a remote tracking branch or
on a tag that the name of the tag or the remote tracking branch is
shown rather than '* (no branch)'.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC] Assorted small changes to runstatus
From: Juergen Ruehle @ 2007-01-03 5:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xgkstzt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Thanks. 3 and 4 are obviously good, 1 is probably good although
> I do not have much preference either way myself. The part that
> adds helpful messages of 2 is nice but I am not sure about the
> wording "Cached changes".
>
> Maybe people who were in the update-index and git-add discussion
> have better input than I can give.
Yes, that was the intention. Thanks for looking at the proposal.
^ permalink raw reply
* Re: How to commit removed file?
From: Michael S. Tsirkin @ 2007-01-03 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vfyatt8di.fsf@assigned-by-dhcp.cox.net>
Mutt Label Removed By VIM
> Quoting r. Junio C Hamano <junkio@cox.net>:
> Subject: Re: How to commit removed file?
>
> >> > I'd like to remove a file and commit the removal while
> >> > leaving out other changes in repository/index.
> >> >
> >> > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
> >> > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
> >> >
> >> > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> >> > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
> >> > any file(s) known to git.
> >> > Did you forget to 'git add'?
> >> >
> >> > A similiar thing works with "git add".
> >>
> >> Any ideas? Can this be done with git?
> >
> > Did you actually try the "--" thing I suggested in
> > http://article.gmane.org/gmane.comp.version-control.git/35699/?
> >
> > Besides, I just tested with current "next":
> >
> > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> > Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
> > 1 files changed, 0 insertions(+), 22 deletions(-)
> > delete mode 100644 a234
>
> The difference is Michael did "git rm" to explicitly tell git to
> forget about that path, while you used the vanilla "/bin/rm".
>
> Personally I never saw the point of having "git rm". Maybe we
> should remove it to prevent this confusion from happening.
But won't the same problem appear with
rm file
git-update-index file
git-commit file
--
MST
^ permalink raw reply
* Re: How to commit removed file?
From: Junio C Hamano @ 2007-01-03 6:51 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Johannes Schindelin, git
In-Reply-To: <20070103060640.GD20259@mellanox.co.il>
"Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> But won't the same problem appear with
>
> rm file
> git-update-index file
> git-commit file
If you do index manipulation yourself using update-index, do not
jump the index at the commit time using "git commit file..."
syntax; the sole purpose of that misfeature is to handhold
CVS-braindamaged people who want to make per-path partial
commits.
We bend backwards to allow index-jumping for most cases in
git-commit, and you found that "most" is not "all". That's a
great news.
I am not interested to make it "all" myself -- if somebody else
does it, that is fine, though ;-).
^ permalink raw reply
* Re: [PATCH] git-branch: show detached HEAD
From: Junio C Hamano @ 2007-01-03 6:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Lars Hjemli, git
In-Reply-To: <20070103051811.GB23358@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Lars Hjemli <hjemli@gmail.com> wrote:
>> This makes git-branch show a detached HEAD as '* (no branch)'.
>
> It would be nicer if when you are on a remote tracking branch or
> on a tag that the name of the tag or the remote tracking branch is
> shown rather than '* (no branch)'.
That would be utterly confusing if you are talking about the
same detached HEAD semantics as I and Carl discussed today. I
like what Lars's patch does (although I felt that it was too big
for only doing this which made it harder to judge), but I would
even make it stronger to say something like:
* You are not on ANY branch right now.
master
next
pu
...
You will never be _on_ a remote tracking branch. So far we did
not allow HEAD to point at outside refs/heads/ and we still
don't. When HEAD is detached from any branch, however, it can
store a bare 40-hex (plus LF) commit object name instead of
being a symref. You are not on any branch at that point.
Most importantly, if we allow commits to be built on top of HEAD
while it is detached from any branch, the commit will _not_
advance any branch. So showing the remote tracking branch the
way you suggest will be misleading.
If we do not allow commits to be built on top, we would still
allow something to be done other than switching out of "detached
mode" to be useful. For example, reset to move around which
commit to look at would be a useful thing. Another of my
unstated desire is to get rid of the use of special "bisect"
branch during bisection using detached HEAD. Again, if we
highlight remote tracking branch whose tip happens to be the
same commit as the current HEAD as you suggest, that would lead
to quite confusing behaviour. Sometimes it would say the same
thing as you are _on_ that branch (which confuses you because
you are _not_ on that branch in reality), sometimes it would
highlight nothing to show you are not on any branch.
^ permalink raw reply
* Re: [PATCH] git-branch: show detached HEAD
From: Junio C Hamano @ 2007-01-03 7:05 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1167780131528-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> This makes git-branch show a detached HEAD as '* (no branch)'.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
>
> This might be a premature patch. But if/when we allow HEAD to be detached,
> git-branch should tell us that HEAD is the current 'branch'.
I fully agree with the motivation, but 100 lines of change to
adjust only to detached HEAD seems too much. What else is going
on in this patch, I wonder...
Can we have two patches, one for loop restructuring without
detached HEAD support, and then another to add support for it?
^ permalink raw reply
* Re: How to commit removed file?
From: Junio C Hamano @ 2007-01-03 7:14 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhcv8r4ac.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ... That's a
> great news.
>
> I am not interested to make it "all" myself -- if somebody else
> does it, that is fine, though ;-).
Just in case you do not know me, sorry for too much negative
tone in my message. I was just venting. It was not like I was
offended by something you said or anything like that.
The "commit path..." feature, while I would even agree that it
sometimes is useful in simple cases, is something that goes
quite against what git does normally, and anybody would
understand why after inspecting what git-commit has to do to
implement that. I personally hate that "feature".
Having said that, I am known to support features that I do not
agree with myself for other people, and sometimes even implement
them myself. But that does not mean I have to like them ;-).
^ 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