* [PATCH 5/5] Enable ref log creation in git checkout -b.
@ 2006-05-19 9:17 Shawn Pearce
2006-05-21 9:42 ` Junio C Hamano
0 siblings, 1 reply; 7+ messages in thread
From: Shawn Pearce @ 2006-05-19 9:17 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Switch git checkout -b to use git-update-ref rather than echo and
a shell I/O redirection. This is more in line with typical GIT
commands and allows -b to be logged according to the normal ref
logging rules.
Added -l option to allow users to create the ref log at the same
time as creating a branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-checkout.txt | 7 ++++++-
git-checkout.sh | 19 +++++++++++++++----
2 files changed, 21 insertions(+), 5 deletions(-)
46409624159100ad958c3168b13e384168c12713
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 0951289..0643943 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -8,7 +8,7 @@ git-checkout - Checkout and switch to a
SYNOPSIS
--------
[verse]
-'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>]
+'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
'git-checkout' [-m] [<branch>] <paths>...
DESCRIPTION
@@ -37,6 +37,11 @@ OPTIONS
-b::
Create a new branch and start it at <branch>.
+-l::
+ Create the new branch's ref log. This activates recording of
+ all changes to made the branch ref, enabling use of date
+ based sha1 expressions such as "<branchname>@{yesterday}".
+
-m::
If you have local modifications to one or more files that
are different between the current branch and the branch to
diff --git a/git-checkout.sh b/git-checkout.sh
index a11c939..360aabf 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -5,10 +5,13 @@ SUBDIRECTORY_OK=Sometimes
. git-sh-setup
old=$(git-rev-parse HEAD)
+old_name=HEAD
new=
+new_name=
force=
branch=
newbranch=
+newbranch_log=
merge=
while [ "$#" != "0" ]; do
arg="$1"
@@ -24,6 +27,9 @@ while [ "$#" != "0" ]; do
git-check-ref-format "heads/$newbranch" ||
die "git checkout: we do not like '$newbranch' as a branch name."
;;
+ "-l")
+ newbranch_log=1
+ ;;
"-f")
force=1
;;
@@ -44,6 +50,7 @@ while [ "$#" != "0" ]; do
exit 1
fi
new="$rev"
+ new_name="$arg^0"
if [ -f "$GIT_DIR/refs/heads/$arg" ]; then
branch="$arg"
fi
@@ -51,9 +58,11 @@ while [ "$#" != "0" ]; do
then
# checking out selected paths from a tree-ish.
new="$rev"
+ new_name="$arg^{tree}"
branch=
else
new=
+ new_name=
branch=
set x "$arg" "$@"
shift
@@ -114,7 +123,7 @@ then
cd "$cdup"
fi
-[ -z "$new" ] && new=$old
+[ -z "$new" ] && new=$old && new_name="$old_name"
# If we don't have an old branch that we're switching to,
# and we don't have a new branch name for the target we
@@ -187,9 +196,11 @@ # be based on them, since we re-set the
#
if [ "$?" -eq 0 ]; then
if [ "$newbranch" ]; then
- leading=`expr "refs/heads/$newbranch" : '\(.*\)/'` &&
- mkdir -p "$GIT_DIR/$leading" &&
- echo $new >"$GIT_DIR/refs/heads/$newbranch" || exit
+ if [ "$newbranch_log" ]; then
+ mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
+ touch "$GIT_DIR/logs/refs/heads/$branchname"
+ fi
+ git-update-ref -m "checkout: Created from $new_name" "refs/heads/$newbranch" $new || exit
branch="$newbranch"
fi
[ "$branch" ] &&
--
1.3.2.g7278
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
2006-05-19 9:17 [PATCH 5/5] Enable ref log creation in git checkout -b Shawn Pearce
@ 2006-05-21 9:42 ` Junio C Hamano
2006-05-24 3:52 ` Shawn Pearce
0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2006-05-21 9:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
I've swallowed all 10 and pushed them out in "pu", but could you
add tests to check the Porcelainish commands you touched with
this series to make sure they all log correctly?
BTW, I noticed that a patch earlier in the series depended on
something not in "master" (it's rfc2822_date from js/fmt-patch
series). Generally I do not want to make a branch hostage of
another branch by introducing a dependency, but for now I'll
pull in early part of js/fmt-patch branch into sp/reflog branch
and see what happens.
If sp/reflog branch graduates to the "master" first, it will
pull early parts of js/fmt-patch along with it, but the built-in
will be called "git fmt-patch" in the result, so it wouldn't
affect the use of "git format-patch".
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
2006-05-21 9:42 ` Junio C Hamano
@ 2006-05-24 3:52 ` Shawn Pearce
2006-05-24 4:32 ` Junio C Hamano
2006-05-24 23:18 ` Junio C Hamano
0 siblings, 2 replies; 7+ messages in thread
From: Shawn Pearce @ 2006-05-24 3:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> I've swallowed all 10 and pushed them out in "pu", but could you
> add tests to check the Porcelainish commands you touched with
> this series to make sure they all log correctly?
Sure. I've been putting it off as I've been busy the past few days
and have also been thinking about trying to rebuild reflog using a
tag/annotation branch style, which might be more generally useful
to others. So I've been debating about whether or not I should
ask you to pop reflog out of pu indefinately.
> BTW, I noticed that a patch earlier in the series depended on
> something not in "master" (it's rfc2822_date from js/fmt-patch
> series). Generally I do not want to make a branch hostage of
> another branch by introducing a dependency, but for now I'll
> pull in early part of js/fmt-patch branch into sp/reflog branch
> and see what happens.
Doh. Sorry about that one. I saw it in date.c and used it, not
realizing it was only in pu.
--
Shawn.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
2006-05-24 3:52 ` Shawn Pearce
@ 2006-05-24 4:32 ` Junio C Hamano
2006-05-24 23:18 ` Junio C Hamano
1 sibling, 0 replies; 7+ messages in thread
From: Junio C Hamano @ 2006-05-24 4:32 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
> Sure. I've been putting it off as I've been busy the past few days
> and have also been thinking about trying to rebuild reflog using a
> tag/annotation branch style, which might be more generally useful
> to others. So I've been debating about whether or not I should
> ask you to pop reflog out of pu indefinately.
Heh, too late for that -- it looked OK so now they are part of
"next" to get wider exposure.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
2006-05-24 3:52 ` Shawn Pearce
2006-05-24 4:32 ` Junio C Hamano
@ 2006-05-24 23:18 ` Junio C Hamano
2006-05-24 23:25 ` Shawn Pearce
2006-05-24 23:36 ` Shawn Pearce
1 sibling, 2 replies; 7+ messages in thread
From: Junio C Hamano @ 2006-05-24 23:18 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> I've swallowed all 10 and pushed them out in "pu", but could you
>> add tests to check the Porcelainish commands you touched with
>> this series to make sure they all log correctly?
>
> Sure. I've been putting it off as I've been busy the past few days
> and have also been thinking about trying to rebuild reflog using a
> tag/annotation branch style, which might be more generally useful
> to others.
It appears that there is more serious breakage caused by the
lock_ref change. http-fetch in "next" fails to clone, because
the call to lock-ref-sha1 in fetch.c::pull() forgets that the
program might be creating a new ref.
Another breakage I found (not related to ref-log) is that it
appears fetch.c, even in "master" branch [*1*], has current_ref
variable and does things depending on it, but nobody seems to
set that variable, so there are a lot of dead code that looks as
if they are doing something useful, enclosed in sections like:
if (somethingelse && current_ref) {
dead code
}
I'll probably revert the ref-log series from "next" in the next
round of updates, while killing the current_ref variable from
"master".
[Footnotes]
*1* It actually is worse than that. Commit cd541a6 introduced
this variable but nobody touches it ever in the development
history of that variable. I wonder what the original author and
the maintainer were smoking back then...
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
2006-05-24 23:18 ` Junio C Hamano
@ 2006-05-24 23:25 ` Shawn Pearce
2006-05-24 23:36 ` Shawn Pearce
1 sibling, 0 replies; 7+ messages in thread
From: Shawn Pearce @ 2006-05-24 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >> I've swallowed all 10 and pushed them out in "pu", but could you
> >> add tests to check the Porcelainish commands you touched with
> >> this series to make sure they all log correctly?
> >
> > Sure. I've been putting it off as I've been busy the past few days
> > and have also been thinking about trying to rebuild reflog using a
> > tag/annotation branch style, which might be more generally useful
> > to others.
>
> It appears that there is more serious breakage caused by the
> lock_ref change. http-fetch in "next" fails to clone, because
> the call to lock-ref-sha1 in fetch.c::pull() forgets that the
> program might be creating a new ref.
Hmm. I thought I was doing the same thing fetch used to do which
appeared to only work on refs which already exist, and not creating
new refs...
> Another breakage I found (not related to ref-log) is that it
> appears fetch.c, even in "master" branch [*1*], has current_ref
> variable and does things depending on it, but nobody seems to
> set that variable, so there are a lot of dead code that looks as
> if they are doing something useful, enclosed in sections like:
>
> if (somethingelse && current_ref) {
> dead code
> }
I wondered about that code...
--
Shawn.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
2006-05-24 23:18 ` Junio C Hamano
2006-05-24 23:25 ` Shawn Pearce
@ 2006-05-24 23:36 ` Shawn Pearce
1 sibling, 0 replies; 7+ messages in thread
From: Shawn Pearce @ 2006-05-24 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >> I've swallowed all 10 and pushed them out in "pu", but could you
> >> add tests to check the Porcelainish commands you touched with
> >> this series to make sure they all log correctly?
> >
> > Sure. I've been putting it off as I've been busy the past few days
> > and have also been thinking about trying to rebuild reflog using a
> > tag/annotation branch style, which might be more generally useful
> > to others.
>
> It appears that there is more serious breakage caused by the
> lock_ref change. http-fetch in "next" fails to clone, because
> the call to lock-ref-sha1 in fetch.c::pull() forgets that the
> program might be creating a new ref.
The breakage is because of current_ref always being null. The old
code would allow locking a non-existant ref in this case while the
new code was failing. A simple change such as the following should
fix it:
-->8--
Fix fetch when using reflog.
Previously fetch was permitted to create refs if they did not exist;
this only worked as current_ref was always NULL and thus never
would get compared against the existing ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
2dad4178db978c01257fde949d808361589ee003
fetch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
2dad4178db978c01257fde949d808361589ee003
diff --git a/fetch.c b/fetch.c
index fd57684..15110b8 100644
--- a/fetch.c
+++ b/fetch.c
@@ -213,7 +213,7 @@ int pull(char *target)
save_commit_buffer = 0;
track_object_refs = 0;
if (write_ref) {
- lock = lock_ref_sha1(write_ref, current_ref, 1);
+ lock = lock_ref_sha1(write_ref, current_ref, 0);
if (!lock) {
error("Can't lock ref %s", write_ref);
return -1;
--
1.3.3.gfad60
^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-05-24 23:36 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-19 9:17 [PATCH 5/5] Enable ref log creation in git checkout -b Shawn Pearce
2006-05-21 9:42 ` Junio C Hamano
2006-05-24 3:52 ` Shawn Pearce
2006-05-24 4:32 ` Junio C Hamano
2006-05-24 23:18 ` Junio C Hamano
2006-05-24 23:25 ` Shawn Pearce
2006-05-24 23:36 ` Shawn Pearce
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).