git stash changes ORIG_HEAD
Hi, I monitor a couple of Git repos by reviewing changes via: % git pull % git log -p -w --no-merges ORIG_HEAD.. This works wonderfully for me. However, sometimes I have pending changes in my repo (because I did not yet committed them to a new branch). I thought I could simply use % git pull --rebase --autostash % git log -p -w --no-merges ORIG_HEAD.. However, this does not work as intended because stashing moves ORIG_HEAD. Right now I use % orig=$(git rev-parse HEAD) % git pull --rebase --autostash % git log -p -w --no-merges orig.. Is it really necessary that ORIG_HEAD is moved while stashing? This does defeat it's purpose because it's always identical to HEAD after the stash is applied. Or could we have an option to not do that? Or is there already another symbolic name I could use? Best, Norbert
Re: config for `format-patch --notes`?
Thanks for the reply. I did not knew that branch descriptions automatically make it in the cover letter. Learned something new! Unfortunately this would still mean I have to manually add the branch name to the branch description. I will try to create a patch for adding a config option for the --notes command line option over the upcoming free days.
Missing option for format-patch?
Hi, I use `git format-patch master..myBranch` quite a bit to send patches to other developers. I also add notes to the commits so that I remember which patches were emailed to whom. `git log` has an option to automatically include the notes in the output. However, I can't find such an option for `git format-patch`. Am I missing something? Another nice option would to to somehow include the branch name in the resulting output. Right now I use either notes or abuse the `--subject` option for this. P.S.: Today I'm sad and proud to say "Ich bin ein Berliner!" --nk
config for `format-patch --notes`?
Hi, I use `git format-patch master..myBranch` quite a bit to send patches to other developers. I also add notes to the commits so that I e.g. remember which patches were emailed to whom. `git log` has an option to automatically include the notes in the output. However, I can't find such an option for `git format-patch`. Am I missing something? Another nice option would to to somehow include the branch name in the resulting output. Right now I use either notes or abuse the `--subject` option for this. P.S.: Today I'm sad and proud to say "Ich bin ein Berliner!" --nk
indent-heuristic, compaction-heuristic combination
Hi, I started using compaction-heuristic with 2.9, and then also (or so I thought) enabled indent-heuristic with 2.11. Only after reading a comment in "Git rev news" I realized that these 2 options are mutually exclusive. I then checked the Git source code and saw that Git first checks the new indent-heuristic and then the old compaction-heuristic. Therefore, anyone who is as stupid as me and enabled both will always (and silently) end up with the older of the two. Apart from better documentation (I know that both are marked experimental, but nevertheless): could we not swap the order in which they are tested so that the newer heuristic wins?
Re: Rebasing cascading topic trees
More things I learned!
So there are (at least) 2 possible approaches: using history, or using
local tracking branches. The latter looks actually nicer to me, with
the exception that if asks for a `git pull`. Using `git pull
--rebase` actually also ends up with the same tree, but I like the
rebase better.
The following 2 scripts show the 2 approaches. Only difference is in
the creation of topic/b and the last rebase command.
# History
mkdir topic; cd topic
git init
date > a; git add a; git commit -m a
date > b; git add b; git commit -m b
git branch -b topic/a
git checkout -b topic1
date > c; git add c; git commit -m c
date > d; git add d; git commit -m d
git checkout -b topic2
date > e; git add e; git commit -m e
date > f; git add f; git commit -m f
git checkout master
date > g; git add g; git commit -m g
echo "before rebase"; git log --oneline --graph --all
git rebase master topic1
echo "after rebase of topic1"; git log --oneline --graph --all
git rebase --onto=topic1 topic1@{1} topic2
echo "after rebase of topic2"; git log --oneline --graph --all
# Tracking
mkdir topic; cd topic
git init
date > a; git add a; git commit -m a
date > b; git add b; git commit -m b
git branch -b topic/a
git checkout -b topic1
date > c; git add c; git commit -m c
date > d; git add d; git commit -m d
git checkout --track topic1 -b topic2
date > e; git add e; git commit -m e
date > f; git add f; git commit -m f
git checkout master
date > g; git add g; git commit -m g
echo "before rebase"; git log --oneline --graph --all
git rebase master topic1
echo "after rebase of topic1"; git log --oneline --graph --all
git rebase --onto=topic1 master topic2
echo "after rebase of topic2"; git log --oneline --graph --all
On Wed, Nov 16, 2016 at 5:45 PM, Jeff King wrote:
> On Wed, Nov 16, 2016 at 04:12:20PM -0800, Norbert Kiesel wrote:
>
>> Yes, `git rebase --onto topic1 topic1@{1} topic2` is the answer!
>
> See also the `--fork-point` option, which (I think) should do this for
> you (and is the default if "topic1" is the configured upstream for
> topic2 and you just run "git rebase").
>
> -Peff
Re: Rebasing cascading topic trees
Yes, `git rebase --onto topic1 topic1@{1} topic2` is the answer!
Thanks so much, learned something new today.
On Wed, Nov 16, 2016 at 3:44 PM, Junio C Hamano wrote:
> Norbert Kiesel writes:
>
>> I currently have a situation with cascading topic branches that I need to
>> rebase
>> regularly. In the picture below, I want to rebase the tree starting with
>> `E` to
>> be rebased onto master (my actually cascade is 4 branches deep).
>>
>> A--B--C--D (master)
>>\
>> E--F (topic1)
>>\
>> G--H (topic2)
>>
>> After running `git rebase --onto master master topic1`, I end up with
>>
>> A--B--C--D (master)
>>| \
>>\ E'--F' (topic1)
>> E--F
>>\
>> G--H (topic2)
>>
>> I then need to also run `git rebase --onto topic1 F topic2` to arrive at the
>> desired
>>
>> A--B--C--D (master)
>>| \
>>\ E'--F' (topic1)
>> E--F \
>>| G'--H' (topic2)
>>\
>> G--H
>>
>> Problem here is that I don't have a nice symbolic name for `F` anymore after
>> the
>> first rebase. Rebasing `topic2` first is not really possible, because I do
>> not
>> have a new graft-point yet. I currently write down `F` ahead of time (or use
>> `reflog` if I forgot) `F`, but I wonder if there is a better solution.
>
> Doesn't topic1@{1} point at "F" after the rebase of the topic1
> finishes?
>
Rebasing cascading topic trees
I currently have a situation with cascading topic branches that I need to rebase regularly. In the picture below, I want to rebase the tree starting with `E` to be rebased onto master (my actually cascade is 4 branches deep). A--B--C--D (master) \ E--F (topic1) \ G--H (topic2) After running `git rebase --onto master master topic1`, I end up with A--B--C--D (master) | \ \ E'--F' (topic1) E--F \ G--H (topic2) I then need to also run `git rebase --onto topic1 F topic2` to arrive at the desired A--B--C--D (master) | \ \ E'--F' (topic1) E--F \ | G'--H' (topic2) \ G--H Problem here is that I don't have a nice symbolic name for `F` anymore after the first rebase. Rebasing `topic2` first is not really possible, because I do not have a new graft-point yet. I currently write down `F` ahead of time (or use `reflog` if I forgot) `F`, but I wonder if there is a better solution.
[Bug?] git notes are not copied during rebase
Hi, I am currently a heavy user of rebasing and noticed that my notes don't get correctly applied, even if notes.rewrite.rebase is set explicitly to true (though manual says that is the default). Below is a use case that shows that a commit on a branch got rebased, but the note was not copied to the new commit. % mkdir notes % cd notes % git init Initialized empty Git repository in /tmp/notes/.git/ % date % git add a % git commit -m c1 [master (root-commit) 2e24a91] c1 1 file changed, 1 insertion(+) create mode 100644 a % git checkout -b mybranch Switched to a new branch 'mybranch' % date % git add b % git commit -m c2 [mybranch 5ef9954] c2 1 file changed, 1 insertion(+) create mode 100644 b % git notes add -m note1 % git log commit 5ef9954 (HEAD -> mybranch) Author: Norbert Kiesel Date: Mon Nov 14 15:48:00 2016 -0800 c2 Notes: note1 commit 2e24a91 (master) Author: Norbert Kiesel Date: Mon Nov 14 15:48:00 2016 -0800 c1 % git notes c39895a0948c17df2028f07c3ec0993a532edabf 5ef9954dbadddfccefe95277be5e7a995335124b % git checkout master Switched to branch 'master' % date % git commit -a -m c3 [master 1368832] c3 1 file changed, 1 insertion(+) % git rebase master mybranch First, rewinding head to replay your work on top of it... Applying: c2 % git log commit 8921cb7 (HEAD -> mybranch) Author: Norbert Kiesel Date: Mon Nov 14 15:48:00 2016 -0800 c2 commit 1368832 (master) Author: Norbert Kiesel Date: Mon Nov 14 15:48:00 2016 -0800 c3 commit 2e24a91 Author: Norbert Kiesel Date: Mon Nov 14 15:48:00 2016 -0800 c1 % git notes c39895a0948c17df2028f07c3ec0993a532edabf 5ef9954dbadddfccefe95277be5e7a995335124b
Re: [PATCH 0/3] fix local_tzoffset with far-in-future dates
There are more strange things happening with dates. One example is that `git commit --date=@4102444799` produces a commit with the correct author date "Thu Dec 31 15:59:59 2099 -0800" (for my local timezone which is Americas/Los_Angeles), while `git commit --date=@4102444800` produces a commit with "now" as author date, as does any other larger number. `date --date=@4102444800` results in "Thu Dec 31 16:00:00 PST 2099". So seems 2100-01-01T00:00:00Z is a hard limit for git when using this format. On Mon, Jun 20, 2016 at 3:21 PM, Jeff King wrote: > On Mon, Jun 20, 2016 at 03:11:23PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > I still don't know how that screwed-up timestamp got _into_ >> > a commit, so perhaps there is another bug lurking. I couldn't convince >> > git to parse anything beyond 2100, and committing with >> > GIT_AUTHOR_DATE='@5758122296 +' works just fine. >> >> Interesting. The weirdest I could come up with was with >> >> GIT_AUTHOR_DATE='@5758122296 - >> >> which gets turned into the same timestamp but with -10039 timezone >> (simply because 99 minutes is an hour and 39 minutes). > > Yeah, as weird as that is, I think it's reasonable. We _could_ turn > nonsense timezones into "+". That doesn't necessarily help the user > much, but at least it's less bizarre than making a 46-year timezone > offset. > > I also looked for other uses of tm_to_time_t without checking for an > error return. Most of them do check. The exception is datestamp(), but > is calling it on the output of localtime(time()), which should generally > be sensible. > > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unable to pull from remote if commit date is in the future
On Mon, Jun 20, 2016 at 12:39 PM, Jeff King wrote: > git cat-file commit 23c07cc | egrep '^author|committer' author Sean D'Epagnier 5758122296 -40643156 committer Sean D'Epagnier 5758122296 -40643156 date --date='@5758122296' returns "Mon Jun 19 15:24:56 PDT 2152" which is what is shown by github. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unable to pull from remote if commit date is in the future
Hmm. On closer inspection that commit 23c07cc that github shows with date 2152-06-19 is already in my local branch. I got confused because locally it is shown with a different date: `git log -1 --format='%ci' 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid. My system is running Debian unstable 64bit. Is git using the time rendering methods from the C library (glibc 2.22-12)? On Mon, Jun 20, 2016 at 11:46 AM, Stefan Beller wrote: > On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel wrote: >> Hi, >> >> I'm following an upstream repo on github. Today morning I saw a new >> commit there, but a `git pull` in my clone did not fetch it and >> instead said "Already up-to-date.". On closer inspection, github >> reports commit time as 2152-06-19. The same project has some other >> commits with commit time in the future that were fetched. My guess is >> that happened when those commits got a child with commit date in the >> past. > > git-pull doesn't care about the commit/author date/time at all. > > All it takes into consideration > is the graph structure of the commits on the local and the remote branch, > i.e. Are there any commits on the remote branch that are not part of the local > branch history? > > >> >> Is there any way to force git pulling that request? (Perhaps I should >> try to tell git that it's really 2152?) > > You need to see if that commit is part of the history of the > remote branch you pulled. > >> >> For the record: the faulty commit is >> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
unable to pull from remote if commit date is in the future
Hi, I'm following an upstream repo on github. Today morning I saw a new commit there, but a `git pull` in my clone did not fetch it and instead said "Already up-to-date.". On closer inspection, github reports commit time as 2152-06-19. The same project has some other commits with commit time in the future that were fetched. My guess is that happened when those commits got a child with commit date in the past. Is there any way to force git pulling that request? (Perhaps I should try to tell git that it's really 2152?) For the record: the faulty commit is https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
