* Re: Deleting remote branch pointed by remote HEAD
From: Sitaram Chamarty @ 2009-01-21 14:52 UTC (permalink / raw)
To: git
In-Reply-To: <e29894ca0901210502n1ed1187bm46669a402ab4fe48@mail.gmail.com>
On 2009-01-21, Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
> I deleted a remote branch which was pointed by HEAD, this way: "git
> push origin :master"
>
> Then for almost every git command, I get this error: "error:
> refs/remotes/origin/HEAD points nowhere!".
>
> I found this situation non-friendly. Fortunately, I could understand
> what's going on. But a new user might be confused.
That's a pretty advanced command for a beginner. I have
people who're only using the GUI (in the presumption that it
will be less confusing or less powerful or whatever) and
have managed to right click on a remote branch, choose
"checkout this branch" and have made commits on it without
knowing they're not on any branch!
I wish I had your problem :-)
^ permalink raw reply
* Re: CR codes from git commands
From: Brent Goodrick @ 2009-01-21 14:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901210930370.7929@racer>
Johannes Schindelin writes:
> Hi,
>
> is there a special reason you un-Cc:ed the list?
No, my mistake. CCing the mailing list now. I was foiled into
thinking that the reply operation in my email client meant reply-all,
but instead it was set to reply-to-sender-only. Now fixed.
>
> On Tue, 20 Jan 2009, Brent Goodrick wrote:
>
> > Johannes Schindelin writes:
> >
> > > On Tue, 20 Jan 2009, Brent Goodrick wrote:
> > >
> > > > I am considering converting from CVS over to using git. I'm
> > > > currently using git version 1.5.6.5 on Debian Linux "testing".
> > >
> > > First of all, 1.5.6.5 is from last August, so chances are that the
> > > behavior you complain about was fixed in the meantime. We're at
> > > 1.6.1 at the moment.
> >
> > Yes, I thought that was a good point, so I rebuilt from the source
> > tarball git version 1.6.1 and retried my script and got the same
> > behavior.
> >
> > > The only place I can think about where a CR is output is when showing
> > > the progress of downloading.
> > >
> > > Usually, our code checks if stdout is a tty, and does not show
> > > progress.
> > >
> > > As a work-around, piping into cat should work, though.
> >
> > Actually only redirecting stderr and then piping to cat seems to work,
> > e.g.,:
> >
> > get pull 2>&1 | cat
> >
> >
> > I don't mind seeing the progress lines, I just don't want git to emit
> > any CR codes at all.
> >
> > How about a config option to just turn off any tty-detecting logic
> > entirely, so that I don't have to wrap git with a lot of silly scripts
> > that set environment variables and redirect stdout and stderr and piped
> > into "cat"?
>
> Nope, the config option is not needed. This is just a Plain Old Bug which
> needs fixing, that's all.
>
> Let's see what I can do today.
Thanks. The fix should be to arrange it so that I can set something
so that a bare call such as (but just "git pull"):
git pull
will emit no CR codes at all, ever, regardless of if there is a tty.
Even if it is an env var, but a config setting would be ok too.
Thanks,
Brent
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Adeodato Simó @ 2009-01-21 14:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Marc-André Lureau, git
In-Reply-To: <49773240.7090605@drmicha.warpmail.net>
* Michael J Gruber [Wed, 21 Jan 2009 15:33:36 +0100]:
> Marc-André Lureau venit, vidit, dixit 21.01.2009 14:02:
> > Hi
> > I deleted a remote branch which was pointed by HEAD, this way: "git
> > push origin :master"
> > Then for almost every git command, I get this error: "error:
> > refs/remotes/origin/HEAD points nowhere!".
> You're talking about about the remote git repo, aren't you?
> > I found this situation non-friendly. Fortunately, I could understand
> > what's going on. But a new user might be confused.
> > Shouldn't the remote HEAD branch be updated or "protected" in some
> > ways? Or should the "error" be considered as a "warning" (silently?)
> > What do you think?
> I think that git said
> "warning: updating the currently checked out branch; this may cause
> confusion,
> as the index and working tree do not reflect changes that are now in HEAD."
> after your push and that this may have rung some bells. I also think
> that pushing to a non-bare remote repo (one with a worktree checked out)
> is strongly advised against in multiple places, unless you know what
> you're doing - which you seem to do since you were able to restore your
> HEAD ;)
I don't think Marc-André was pushing to a non-bare repo, but it doesn't
really matter, because his issue also shows up with bare repos: if you
delete the branch to which HEAD points in a remote repo, you get no
warning, and then cloning that bare repo does not fully work, because
its HEAD points to a non-existent ref.
% g clone ssh://.../foo.git
% cd foo
% g push origin :master
% cd ..
% g clone ssh://.../foo.git foo2
...
warning: remote HEAD refers to nonexistent ref, unable to checkout.
What would git usefully do in this situation, I don't know. But I
thought I'd clear up the above confusion.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Truth is the most valuable thing we have, so let's economize it.
-- Mark Twain
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Marc-André Lureau @ 2009-01-21 14:38 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49773240.7090605@drmicha.warpmail.net>
On Wed, Jan 21, 2009 at 4:33 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Marc-André Lureau venit, vidit, dixit 21.01.2009 14:02:
>> Hi
>>
>> I deleted a remote branch which was pointed by HEAD, this way: "git
>> push origin :master"
>>
>> Then for almost every git command, I get this error: "error:
>> refs/remotes/origin/HEAD points nowhere!".
>
> You're talking about about the remote git repo, aren't you?
>
Sure. But the error is on the local repo.
>> I found this situation non-friendly. Fortunately, I could understand
>> what's going on. But a new user might be confused.
>>
>> Shouldn't the remote HEAD branch be updated or "protected" in some
>> ways? Or should the "error" be considered as a "warning" (silently?)
>>
>> What do you think?
>
> I think that git said
> "warning: updating the currently checked out branch; this may cause
> confusion,
> as the index and working tree do not reflect changes that are now in HEAD."
IIRC, it only says so if your local repo is on a branch tracking this
remote. At least, in some conditions, I didn't get this warning. When
I did second simple testing with git.git version, I also had this
warning.
> after your push and that this may have rung some bells. I also think
> that pushing to a non-bare remote repo (one with a worktree checked out)
> is strongly advised against in multiple places, unless you know what
> you're doing - which you seem to do since you were able to restore your
> HEAD ;)
Isn't HEAD also on non-bare repo, to indicate what is the default branch?
thanks,
--
Marc-André Lureau
^ permalink raw reply
* [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-21 14:37 UTC (permalink / raw)
To: git
There are some files that I can't merge with git, and sometimes you
just want to finish merging later or move on to the next file and come
back later. My patch allows you to quit mergetool without ctrl-c, or
move on to the next file or merge the this one. pretty simple and I
think will be useful for a lot of people.
>From b647762ad179cdaaf9f844671fdf26074563b366 Mon Sep 17 00:00:00 2001
From: Caleb Cushing <xenoterracide@gmail.com>
Date: Tue, 20 Jan 2009 11:33:30 -0500
Subject: [PATCH] mergetool merge/skip/abort
add functionality to skip merging a file or abort from the merge
---
git-mergetool.sh | 24 ++++++++++++++++++++----
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..43d2a9e 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -177,11 +177,27 @@ merge_file () {
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
if "$prompt" = true; then
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
- fi
+ while true; do
+ printf "Use (m)erge file or (s)skip file, or (a)bort? (%s): " \
+ "$merge_tool"
+ read ans
+ case "$ans" in
+ [mM]*)
+ break
+ ;;
+ [sS]*)
+ cleanup_temp_files
+ return 0
+ ;;
+ [aA]*)
+ cleanup_temp_files
+ exit 0
+ ;;
+ esac
+ done
+ fi
- case "$merge_tool" in
+ case "$merge_tool" in
kdiff3)
if base_present ; then
("$merge_tool_path" --auto --L1 "$MERGED (Base)" --L2
"$MERGED (Local)" --L3 "$MERGED (Remote)" \
--
1.6.1
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Sebastien Cevey @ 2009-01-21 14:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Giuseppe Bilotta
In-Reply-To: <200901120225.30175.jnareb@gmail.com>
Selon Jakub Narebski <jnareb@gmail.com>:
Hello,
Sorry for not responding earlier, I was quite busy being ill and moving abroad
for a new job.
> >>> ----------------------------------------------------------------
> >>> [Actively cooking]
> >>>
> >>> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
> >>> - gitweb: Optional grouping of projects by category
> >>> - gitweb: Split git_project_list_body in two functions
> >>> - gitweb: Modularized git_get_project_description to be more generic
> >>
> >> This I think needs some further cooking. I guess with addition of one
> >> more patch to series categories could be sorted together with projects
> >> they contain, and not always have to be in fixed ordering.
> >
> > These should be moved to the Stalled category; nobody seems to be
> > discussing improvements and sending updates to the series as far as I
> > recall.
>
> I think it is just the author being slow moving; there was quite
> a bit of time between subsequent versions of this patch series.
I don't recall what was left to do on top of the series of patches I submitted,
could you refresh my mind on that if it still needs to be done? I remember the
discussion trailing off as categorized ordering was being discussed..
--
Sebastien Cevey - inso.cc
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Michael J Gruber @ 2009-01-21 14:33 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: git
In-Reply-To: <e29894ca0901210502n1ed1187bm46669a402ab4fe48@mail.gmail.com>
Marc-André Lureau venit, vidit, dixit 21.01.2009 14:02:
> Hi
>
> I deleted a remote branch which was pointed by HEAD, this way: "git
> push origin :master"
>
> Then for almost every git command, I get this error: "error:
> refs/remotes/origin/HEAD points nowhere!".
You're talking about about the remote git repo, aren't you?
> I found this situation non-friendly. Fortunately, I could understand
> what's going on. But a new user might be confused.
>
> Shouldn't the remote HEAD branch be updated or "protected" in some
> ways? Or should the "error" be considered as a "warning" (silently?)
>
> What do you think?
I think that git said
"warning: updating the currently checked out branch; this may cause
confusion,
as the index and working tree do not reflect changes that are now in HEAD."
after your push and that this may have rung some bells. I also think
that pushing to a non-bare remote repo (one with a worktree checked out)
is strongly advised against in multiple places, unless you know what
you're doing - which you seem to do since you were able to restore your
HEAD ;)
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] [TOPGIT] make tg remote idempotent
From: martin f krafft @ 2009-01-21 14:31 UTC (permalink / raw)
To: Uwe Kleine-König, git, Petr Baudis
In-Reply-To: <20090121110628.GA9415@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
also sprach Uwe Kleine-König <ukleinek@strlen.de> [2009.01.21.2206 +1100]:
> I fixed this in my repo. Should I resend the fixed patch?
No, I will pull. Cheers,
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"arthur slapped his arms about himself to try and get his
circulation a little more enthusiastic about its job."
-- hitchhiker's guide to the galaxy
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Newbie Query
From: Chris Willard @ 2009-01-21 14:31 UTC (permalink / raw)
To: Git List
In-Reply-To: <20090120191952.GA25322@uts.thewillards.local>
On Tue, 20 Jan 2009, Chris Willard wrote:
> Hello All,
>
> I am having a go at using git and need a bit of help.
[snip]
Thanks for all the tips - I used "git-reset --hard" to solve my
problem.
Regards,
Chris
--
-----------( "The Batman play seemed important to Crow." -- )------------
-----------( Mike Nelson )------------
Chris -----( )---- Willard
Htag.pl 0.0.23
--
This message was scanned by ESVA and is believed to be clean.
^ permalink raw reply
* Re: feature request mergetool, skip, abort
From: Caleb Cushing @ 2009-01-21 14:26 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20090121112236.GC18488@hashpling.org>
patch was an attachement.
after looking through the list and seeing the conventions I've a fully
working one now, so I'm going to start a new thread with it.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Jeff King @ 2009-01-21 13:32 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20090121125619.GA523@atjola.homenet>
On Wed, Jan 21, 2009 at 01:56:19PM +0100, Björn Steinbrink wrote:
> Another possible solution would be to free the blob data only after the
> loop in diffcore_rename has finished, but that's obviously quite bad WRT
> memory consumption. :-)
Yeah, and it doesn't have the (admittedly smaller, but still there)
optimization of not loading the blob data at all if we will never need
to.
> Anyway, too late, yesterday's attempts 6 to 10 at writing a better
> commit message didn't work out either, and Junio has applied the patch
> by now.
I think that's fine. My message was more about convincing myself that
your change was the right thing (and hopefully helped convince others,
too).
-Peff
^ permalink raw reply
* Deleting remote branch pointed by remote HEAD
From: Marc-André Lureau @ 2009-01-21 13:02 UTC (permalink / raw)
To: git
Hi
I deleted a remote branch which was pointed by HEAD, this way: "git
push origin :master"
Then for almost every git command, I get this error: "error:
refs/remotes/origin/HEAD points nowhere!".
I found this situation non-friendly. Fortunately, I could understand
what's going on. But a new user might be confused.
Shouldn't the remote HEAD branch be updated or "protected" in some
ways? Or should the "error" be considered as a "warning" (silently?)
What do you think?
regards,
--
Marc-André Lureau
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Björn Steinbrink @ 2009-01-21 12:56 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20090120212723.GA10967@coredump.intra.peff.net>
On 2009.01.20 16:27:23 -0500, Jeff King wrote:
> So I think your patch is absolutely the right thing to do. But I think
> from the commit message it isn't clear that it would not be equally
> correct to follow through on generating cnt_data instead of an early
> return (which _isn't_ right, because you might not need to generate
> cnt_data at all).
Yeah, the commit message wasn't exactly great, but after the fifth
attempt I decided to just sent the damn thing, to see whether at least
the patch itself makes sense.
Another possible solution would be to free the blob data only after the
loop in diffcore_rename has finished, but that's obviously quite bad WRT
memory consumption. :-)
Anyway, too late, yesterday's attempts 6 to 10 at writing a better
commit message didn't work out either, and Junio has applied the patch
by now.
Björn
^ permalink raw reply
* Re: how to git a read only directory
From: Boaz Harrosh @ 2009-01-21 12:34 UTC (permalink / raw)
To: git
In-Reply-To: <20090121083354.GG6970@b2j>
bill lam wrote:
> I want to use git to keep track of files inside /etc but do not want
> to do it as a super user. Is that possible to put GIT_DIR under my
> home directory and add public-read files inside /etc? Or that it could
> be done in some other ways.
>
> Thanks.
>
I did the really easy hack (on my /etc BTW) and it worked fine for me.
I created a master project folder under ~home, init a new git repo,
then symlink /etc/ onto an etc/ in the project dir, added all etc/
files. I like the extra a/etc/fstab in the patch files better then
a/fstab.
And it is a life saver, payed it's effortless in gold. Some shining
new distro should come up with a git based management system
and it will leave all the other distros in the dust.
Cheers
Boaz
^ permalink raw reply
* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-21 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vskndgi3c.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 21 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This patch adds the ability to use valgrind's memcheck tool to
> > diagnose memory problems in git while running the test scripts....
>
> Hmmm, why do I haf to suffer with these new warnings from the tests?
>
> $ sh t2012-checkout-last.sh --valgrind -v -i
> warning: templates not found /git/git.git/t/valgrind/bin/templates/blt/
> Initialized empty Git repository in /git/git.git/t/trash directory.t2012-checkout-last/.git/
> mv: cannot stat `.git/hooks': No such file or directory
> * expecting success:
> echo hello >world &&
>
> Am I using the patch incorrectly somehow?
Nope, I overlooked that GIT_EXEC_PATH was used by test-lib also to
determine the location of the templates. Will squash this in (which
makes a function out of the symlink business, and also fixes the error
that git-gui/ was tested if it is a script; "head" complained that it is
not a file):
-- snipsnap --
t/test-lib.sh | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f031905..6acc6e0 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -487,6 +487,14 @@ then
PATH=$TEST_DIRECTORY/..:$PATH
GIT_EXEC_PATH=$TEST_DIRECTORY/..
else
+ make_symlink () {
+ test -h "$2" &&
+ test "$1" = "$(readlink "$2")" || {
+ rm -f "$2" &&
+ ln -s "$1" "$2"
+ }
+ }
+
# override all git executables in PATH and TEST_DIRECTORY/..
GIT_VALGRIND=$TEST_DIRECTORY/valgrind/bin
mkdir -p "$GIT_VALGRIND"
@@ -498,12 +506,13 @@ else
while read file
do
# handle only executables
- test -x "$file" && test ! -d "$file" || continue
+ test -x "$file" || continue
base=$(basename "$file")
symlink_target=$TEST_DIRECTORY/../$base
# do not override scripts
if test -x "$symlink_target" &&
+ test ! -d "$symlink_target" &&
test "#!" != "$(head -c 2 < "$symlink_target")"
then
symlink_target=../valgrind.sh
@@ -513,19 +522,16 @@ else
symlink_target=../unprocessed-script
esac
# create the link, or replace it if it is out of date
- if test ! -h "$GIT_VALGRIND"/"$base" ||
- test "$symlink_target" != \
- "$(readlink "$GIT_VALGRIND"/"$base")"
- then
- rm -f "$GIT_VALGRIND"/"$base" || exit
- ln -s "$symlink_target" "$GIT_VALGRIND"/"$base"
- fi
+ make_symlink "$symlink_target" "$GIT_VALGRIND/$base" ||
+ exit
done
done
IFS=$OLDIFS
PATH=$GIT_VALGRIND:$PATH
GIT_EXEC_PATH=$GIT_VALGRIND
export GIT_VALGRIND
+
+ make_symlink ../../../templates "$GIT_VALGRIND"/templates || exit
fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
--
1.6.1.442.g38a50
^ permalink raw reply related
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Johannes Schindelin @ 2009-01-21 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vr62xezm8.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 21 Jan 2009, Junio C Hamano wrote:
> Having said all that, I think Dscho's one had an off-by-one (but it is
> getting late and it may be I who has one).
Yep, I missed the "\n" at the end.
Ciao,
Dscho
^ permalink raw reply
* Re: how to keeping track of cherry-pick?
From: Johannes Schindelin @ 2009-01-21 12:04 UTC (permalink / raw)
To: Knut Olav Bøhmer; +Cc: git, Junio C Hamano
In-Reply-To: <4976E059.6000404@telenor.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2356 bytes --]
Hi,
On Wed, 21 Jan 2009, Knut Olav Bøhmer wrote:
> Junio C Hamano wrote:
> > Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
> >
> >> svnmerge.py can give us a list of revisions available for merging. The
> >> result is similar to "git log --chery-pick master..dev" The difference
> >> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
> >> at the diffs. The result of that is that when we get a conflict when a
> >> patch is cherry-picked, it will still show up as "available" when I run
> >> "git log --cherry-pick master..dev"
> >
> > I think you are looking at it a wrong way.
> >
> > Because subversion (at least the older one) does not keep track of merges,
> > you had to track cherry-picks. But cherry-pick is not how you usually do
> > things in git. You keep many topic branches with different doneness, and
> > you merge well-cooked ones to the more stable integration branch while
> > leaving others still cooking. So what you want to know is not cherry-pick
> > status, but merge status.
>
>
> I was afraid I would get this answer. I know that you change your
> workflow when you migrate to git, but I was looking for a way to resolve
> the situation we are in, due to our old vcs.
You could accomodate your workflow by having the newly introduced commit
notes provide a mapping of which commits reflect which patch, in a way
introducing equality classes of patches (thereby having the original SHA-1
of the commit as kind of a "patch id").
But believe me, you would regret it.
If you are working on different topics, and want to apply only some of
them, you really want to have different topic branches (it is even
relatively easy to create them using "git checkout -b <new-topic>
<miscellaneous-branch> && git rebase -i master" and then deleting the
commits not referring to a certain subject).
The problem with having a single branch is that patches which are
independent, can touch the same parts of the code, and are hard to manage
independently. If you had them in topic branches, merging them
individually, you could at least use the rerere mechanism to resolve merge
conflicts for such overlapping topics.
I speak of experience: my current workflow is exactly what you described,
and I feel the pain. That's why I said you would regret it, because I
sure do.
Ciao,
Dscho
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Johannes Schindelin @ 2009-01-21 11:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vwscpgi7t.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 21 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > sha1_name.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/sha1_name.c b/sha1_name.c
> > index 4d10705..803f9d2 100644
> > --- a/sha1_name.c
> > +++ b/sha1_name.c
> > @@ -735,7 +735,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
> > if ((target = strstr(match, " to ")) != NULL) {
> > len = target - match;
> > target += 4;
> > - if (target[len] == '\n' && !strncmp(match, target, len))
> > + if (len == strlen(target) && !strncmp(match, target, len))
> > return 0;
> > }
> > else
>
> Actually, I think this patch to a884d0c (sha1_name: tweak @{-N} lookup,
> 2009-01-17) would make more sense.
>
> -- >8 --
> Subject: [PATCH] Simplify parsing branch switching events in reflog
>
> We only accept "checkout: moving from A to B" newer style reflog entries,
> in order to pick up A. There is no point computing where B begins at
> after running strstr to locate " to ", nor adding 4 and then subtracting 4
> from the same pointer.
Yeah, you're right.
Ciao,
Dscho
^ permalink raw reply
* Re: feature request mergetool, skip, abort
From: Charles Bailey @ 2009-01-21 11:22 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901200839q361923f1xb25ddadfdac37981@mail.gmail.com>
On Tue, Jan 20, 2009 at 11:39:59AM -0500, Caleb Cushing wrote:
> firstly my patch sucks, and I know it. but hopefully it'll give some
> idea of what I'm trying to do and someone can implement it properly.
>
> basically there are some files, that I can't merge with git, but I
> need to merge other files before I can fix those and I like to use
> mergetool, so I want a way to skip the files I'm not going to be able
> to merge.
>
For some reason I couldn't see a patch, but I like the idea of this
from the description and I was at very early stage of working on
something similar myself but it stalled due to other commitments.
For the moment the only way to 'skip' files is by passing full paths
of what you *don't* want to skip to mergetool which isn't really the
same thing at all.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: Few Questions
From: R. Tyler Ballance @ 2009-01-21 11:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, m.arya, git
In-Reply-To: <20090120160410.GI14053@spearce.org>
On Tue, 2009-01-20 at 08:04 -0800, Shawn O. Pearce wrote:
> <plug type="not-quite-ready-but-will-be-soon">
>
> Gerrit2 is also likely to enter this "market" soon. I'm trying to
> get it production ready and live for one major project before the
> end of this month. It embeds its own SSH daemon on a non-standard
> port, completely disconnected from the OS authentication. This may
> make it slightly more palatable in some enviroments then Gitosis,
> as you don't need a huge authorized_keys file, and you don't have
> to worry quite so much about attack vectors.
> </plug>
>
<plug type="not-really-existent-yet-but-gee-golly-i-wish-it-were"
variant="mildly-offtopic" unnecessary:attribute="is-unnecessary">
I talked with Chris Wanstrath (defunkt) of Git Hub once upon a time
about them open sourcing their additions onto the openSSH sshd(8) to
work public key lookup into a MySQL database instead of simply reading a
flat file.
It'd be nice to add some peer pressure to get them to release it
already ;)
</plug>
I read your thread(s) on groups.google.com regarding Gerrit2 and it
seems quite promising as well. Looking forward to it being ready ;)
Cheers
--
-R. Tyler Ballance
Slide, Inc.
^ permalink raw reply
* Re: [PATCH] [TOPGIT] make tg remote idempotent
From: Uwe Kleine-König @ 2009-01-21 11:06 UTC (permalink / raw)
To: git; +Cc: martin f. krafft, Petr Baudis
In-Reply-To: <1231968443-13960-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hello,
On Wed, Jan 14, 2009 at 10:27:22PM +0100, Uwe Kleine-König wrote:
> -git config --add "remote.$name.fetch" "+refs/top-bases/*:refs/remotes/$name/top-bases/*"
> -git config --add "remote.$name.push" "+refs/top-bases/*:refs/top-bases/*"
> -git config --add "remote.$name.push" "+refs/heads/*:refs/heads/*"
> +git config --replace-all "remote.$name.fetch" "+refs/top-bases/*:refs/remotes/$name/top-bases/*" "+refs/top-bases/*:refs/remotes/$name/top-bases/*"
> +git config --replace-all "remote.$name.push" "+refs/top-bases/*:refs/top-bases/*" "+refs/top-bases/*:refs/top-bases/*"
> +git config --replace-all "remote.$name.push" "+refs/heads/*:refs/heads/*" "+refs/heads/*:refs/heads/*"
It seems I sent an old version of this patch. Actually in the last
argument '+' and '*' have to be quoted to work.
I fixed this in my repo. Should I resend the fixed patch?
Best regards
Uwe
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Junio C Hamano @ 2009-01-21 10:27 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Linus Torvalds, git
In-Reply-To: <20090120155957.GA23237@atjola.homenet>
Thanks.
^ permalink raw reply
* Re: [PATCH] color-words: Support diff.wordregex config option
From: Junio C Hamano @ 2009-01-21 10:27 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Johannes Schindelin, Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <200901202146.58651.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> When diff is invoked with --color-words (w/o =regex), use the regular
> expression the user has configured as diff.wordregex.
>
> diff drivers configured via attributes take precedence over the
> diff.wordregex-words setting. If the user wants to change them, they have
> their own configuration variables.
>
> Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
> ---
> This version is squashed into one patch and includes documentation and
> rewritten tests. It was generated against js/diff-color-words~2,
> 80c49c3d (color-words: make regex configurable via attributes), replacing
> my previous 2 patches. It uses "diff.wordregex" for reasons mention by
> Dscho and because that was already what the diff drivers were using.
Nicely done and very well described. I fixed the Subject: line, though ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Junio C Hamano @ 2009-01-21 10:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Markus Heidelberg, Boyd Stephen Smith Jr., Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901202202370.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Subject: Rename diff.suppress-blank-empty to diff.suppressBlankEmpty
>
> All the other config variables use CamelCase. This config variable should
> not be an exception.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix naming scheme for configure cache variables.
From: Junio C Hamano @ 2009-01-21 10:26 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20090119203436.GB3539@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> In order to be cached, configure variables need to contain the
> string '_cv_', and they should begin with a package-specific
> prefix in order to avoid interfering with third-party macros.
> Rename ld_dashr, ld_wl_rpath, ld_rpath to git_cv_ld_dashr etc.
>
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Thanks.
^ 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