dorgflow icon indicating copy to clipboard operation
dorgflow copied to clipboard

come up with another way to mark local commits, as git rebase doesn't like empty commits

Open joachim-n opened this issue 7 years ago • 3 comments

We currently use an empty commit to mark the point when a user makes a local patch. (This is so that future patches can make an interdiff against it, and also so the user can easily see where work was.)

Git rebase removes empty commits, which means that if the user rebases their feature branch against the master branch, these a lost.

Git rebase has a --keep-empty option, which allows these empty commits to be kept, however, using this option is buggy: any commit that fails to apply (which is always a possibility with a rebase) cause the rebase to completely break: see http://git.661346.n2.nabble.com/PATCH-0-2-rebase-broken-behavior-with-keep-empty-td7643204.html

So we need a different system.

The only thing I can think of is to make TWO commits:

  • one that adds a dummy file, with a placeholder commit message
  • one that removes the file, and has the meaningful commit message with all the data.

This is a bit ugly, but prevents the commit from being empty.

Questions:

  • does git accept a commit of an empty file? Or does this dummy file also need to contain something?
  • what's a safe name to call the file? 'dorgflow-dummy.txt' maybe?

(Another idea would be to use tags instead of commits, but those don't survive a rebase either.)

joachim-n avatar Mar 29 '17 10:03 joachim-n

Thought a bit about this. We could

  • create a temporary branch
  • apply all previous interdiffs sequentally
  • merge this --no-ff to the feature branch

This way the remte work is always in one commit while the interdiffs are there too. I don't think that the interdiffs will survive a rebase, but i could live with that.

OR we can just re-generate the remote work and use that as base.

geek-merlin avatar May 13 '17 00:05 geek-merlin

Not sure I follow what you mean, sorry.

This isn't about running the update command and getting new patches, it's about users doing a git rebase themselves when the master branch has moved on.

joachim-n avatar May 21 '17 13:05 joachim-n

yes, i might be more explicit: the goal is:

  • dorglow applies some d.o patches
  • in the middle of the work after some time the user rebases to catch up with upstream
  • user calls dorgflow to finish
  • dorgflow needs a way to separate old d.o patches from new stuff

what i think is

  • dorgflow is on 12345 branch
  • dorgflow creates a temporary branch
  • dorgdlow applies d.o patches one by one
  • dorgflow does git checkout 12345; git merge --no-ff temporary
  • result: d.o patches are wrapped in a single merge commit, while user can still see all interdiffs in the temporary branch
  • user does a rebase
  • result: d.o work is stimm in a single commit, all othe commits must be from the user

note: ordinary rebase does not preserve the merge. if the user wants to rebase all single commits, they should be taught to use git rebase --preserve-merges (*)

geek-merlin avatar May 21 '17 22:05 geek-merlin